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>
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).
Then I got that libvirt stops calling virStorageFileGetMetadataRecurse 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
But in qemu config it was marked as secure hole.
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
Thanks!
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
Thanks!
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
