-blockdev bug (and some questions)

[Cole Robinson <crobinso@xxxxxxxxxx>]

Hi Peter + list,

I'm testing libvirt -blockdev, using your enablement patches from here: 
https://www.redhat.com/archives/libvir-list/2019-September/msg00524.html

I'm hitting an issue but the fix isn't clear to me. Take a VM with 
standard disk XML, using a qcow2 image with a backing file

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/OVERLAY.qcow2'/>
      <target dev='vda' bus='virtio'/>
    </disk>

The VM starts fine, generated -blockdev options are:

-blockdev 
'{"driver":"file","filename":"/BACKING.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' 
\
-blockdev 
'{"node-name":"libvirt-2-format","read-only":true,"driver":"qcow2","file":"libvirt-2-storage","backing":null}' 
\
-blockdev 
'{"driver":"file","filename":"/OVERLAY.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' 
\
-blockdev 
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' 
\

Stop the VM. Edit the disk XML to have a single stub <backingStore/> 
element:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/OVERLAY.qcow2'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
    </disk>

(FWIW my VM just happened to have this element in the XML, not sure 
where it came from, maybe some wayward XML edit at some point)

Start the VM. It starts, but it's not using the backing file, so things 
don't really work. The generate -blockdev bits are:

-blockdev 
'{"driver":"file","filename":"/OVERLAY.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' 
\
-blockdev 
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' 
\

This all works correctly with non-blockdev master. The difference comes 
from this code in qemuProcessPrepareHostStorage:

  /* backing chain needs to be redetected if we aren't using blockdev */
  if (!blockdev)
      virStorageSourceBackingStoreClear(disk->src);

The <backingStore/> causes a disk->src->backingStore to be allocated by 
the domain_conf XML parser. On git master it is removed here. Later in 
qemuDomainDetermineDiskChain, it basically only probes the root image 
file if !disk->src->backingStore. Since the blockdev case doesn't call 
BackingStoreClear, the root image file is never probed in 
qemuDomainDetermineDiskChain, which causes the differing behavior.

Do you have a suggestion for a proper fix? I can try implementing it if 
you'd like, it will help me better understand this stuff.

More generally I have questions about why we track backingStore in the 
XML for an offline VM anyways? I presume this is intentional, but I 
don't understand the usecases. Can you provide more info or link me to 
somewhere if this has been discussed before?

FWIW the XML docs claim backingStore is output only, but seems to 
contradict itself in the next sentence, and they aren't helping me much 
to understand the big picture: 
https://libvirt.org/formatdomain.html#elementsDisks

Thanks,
Cole

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list