Re: [libvirt-users] Change in treatment of qcow2 with chained backing files in v5.10.0?

On Mon, Dec 16, 2019 at 12:49:40 +0100, Jens John wrote: Hi Jens, Yes, this change was done by me when enabling the new way to configure block devices in qemu. I think I know what's going on: So this output was obtained by 'file'. That unfortunately doesn't give enough information. Please run 'qemu-img info' on those files and look for the 'backing file format:'field. That field is important, because otherwise we'd fall back to image format detection which was deemed unsafe and libvirt no longer allows it. $ qemu-img info pull4.qcow2 image: pull4.qcow2 file format: qcow2 virtual size: 10 MiB (10485760 bytes) disk size: 196 KiB cluster_size: 65536 backing file: pull3.qcow2 backing file format: qcow2 ^^^^^^^^^^^^^^^^^^^^^^^^^^ Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false The root of the problem is that the images mentioned above will not have the format section because -F argument for qemu-img was not used when creating them. This would force libvirt to use format detection which is insecure and thus libvirt does not do that and assumes the image is raw. This in normal circumstances causes problems right away, because when running any more advanced security model than unix permissions (selinux apparmor) libvirt would not allow qemu to access the backing file. You don't seem to be running it so it was accidentally working for you until now. -blockdev {"driver":"file","filename":"/home/joj/lib/vm/windows/windows7-taintable.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":true,"driver":"raw","file":"libvirt-2-storage"} Here you can see that the /home/joj/lib/vm/windows/windows7-taintable.qcow2 image was considered being 'raw' this is usually because you didn't record the approprate format. This means that qemu will no longer open the backing image. This is the manifestation of the above problem. -blockdev {"driver":"file","filename":"/home/joj/lib/vm/windows/windows7-Office2013.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"}+} So as a first thing you should create the images properly. This means that when you are creating the overlay image, you have to use the '-F' parameter of qemu-img create. (Note that snapshots/overlays created by libvirt always do this). The -F parameter specifies the format of the backing image specified by -b: qemu-img create -f qcow2 -F qcow2 -b windows7-taintable.qcow2 windows7-Office2013.qcow2 For fixing the image you can use the qemu-img rebase: qemu-img rebase -f qcow2 -F qcow2 -b /home/joj/lib/vm/windows/windows7-taintable.qcow2 windows7-Office2013.qcow2 Please use full paths for the -b argument unless you want relative relationships between images. A second option is to specify the image chain in the XML. This works starting from libvirt 5.10 : <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/joj/lib/vm/windows/windows7-Office2013.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> <backingStore type='file'> <format type='qcow2'/> <source file='/home/joj/lib/vm/windows/windows7-taintable.qcow2'/> <backingStore type='file'> <format type='qcow2'/> <source file='/home/joj/lib/vm/windows/windows7-base.qcow2'/> <backingStore/> </backingStore> </backingStore> </disk> Note that this does not fix the images so they will work only with the above XML. As a last possibility you can disable the 'blockdev' feature in /etc/libvirt/qemu.conf. I will not be more specific on how to do it as it's mostly for debugging purposes and could break stuff in the future. Lastly this is more-or-less tracked in: https://bugzilla.redhat.com/show_bug.cgi?id=1588373 I think I should finally fix it and report a proper error rather than silently assuming it might work. With -blockdev it will never work properly anyways.