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.