[libvirt] external snapshots bug
Peter Krempa
pkrempa at redhat.com
Wed Sep 13 07:47:24 UTC 2017
On Tue, Sep 12, 2017 at 20:49:12 +0300, Khasan Khafizov wrote:
> Suppose we have a disk with several external snapshots of it. This disk is
> attached to some domain. I found that after destroying and starting the
> domain the xml of attached disk doesn't contain all backingStore that it
> has to.
>
> Before the restart the part of domain xml that relates to attached disk
> looks like this:
>
> <disk type='file' device='disk'>
> > <driver name='qemu' type='qcow2'/>
> > <source file='...'/>
> > <backingStore type='file' index='1'>
> > <format type='qcow2'/> <!-- here is qcow2 -->
> > <source file='...'/>
> > <backingStore type='file' index='2'>
> > <format type='qcow2'/>
> > <source file='...'/>
> > <backingStore type='file' index='3'>
> > <format type='qcow2'/>
> > <source file='...'/>
> > <backingStore/>
> > </backingStore>
> > </backingStore>
> > </backingStore>
> > </disk>
>
>
> And after the restart like this:
>
> <disk type='file' device='disk'>
> > <driver name='qemu' type='qcow2'/>
> > <source file='...'/>
> > <backingStore type='file' index='1'>
> > <format type='raw'/> <!-- here is raw -->
> > <source file='...'/>
> > <backingStore/>
> > </backingStore>
> > </disk>
Did you create the snapshot by specifying --reuse-external and providing
a pre-created qcow2 image?
>
> So, the difference in two xml not only in depth of backing stores but in
> format type also.
> The result of it is that you can't run blockcommit that will commit overlay
> into base image if they don't have direct relations (if for example overlay
> is child of child of base image). Virsh says it can't find base in chain (
> exception
> <https://github.com/libvirt/libvirt/blob/cdecfbed027ab242467580a897a636be82d5d411/src/util/virstoragefile.c#L1667>
> ).
> Then I got that libvirt stops calling virStorageFileGetMetadataRecurse
> <https://github.com/libvirt/libvirt/blob/ed8661a309c96e4a1573dc0ca2c76ea7ff19469a/src/storage/storage_source.c#L394>
> function
> after first call because it thinks that format of first backingStore of
> disk is raw instead of qcow2. I solved it by adding to the qemu config
> the following line:
>
> > allow_disk_format_probing = 1
This is insecure.
>
> But in qemu config it was marked as secure hole.
Yep.
> Idea of fix is that we can try assume that backing store of qcow is qcow
> insted of raw, but I really don't know what to do to implement this idea if
> it at all possible
If you are pre-creating the images you have to specify -o
backing_fmt=qcow2 when creating them. Otherwise libvirt will treat it as
raw since probing is not allowed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170913/b967f068/attachment-0001.sig>
More information about the libvir-list
mailing list