Description of problem: When creating a libvirt domain using XML, it used to be possible to specify a disk which was a qcow2 file that was backed by another qcow2 file, simply by pointing to the top qcow2 file, and libvirt would figure out what to do. Now, if I do this, it mistakenly marks the format backing file as "raw" instead of "qcow2", redering the virtual disk unreadable. Version-Release number of selected component (if applicable): 5.10.0 How reproducible: 100% Steps to Reproduce: 1. Create a qcow2 disk called backing.qcow2, containing some data. 2. Create another qcow2 disk called disk.qcow2 backed by backing.qcow2 3. Create a domain XML pointing to disk.qcow2 file as the source of some disk, and not specifying any backing file. Like this: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/vmdata/disk.qcow2'/> <target dev='vda' bus='virtio'/> </disk> 4. Start the domain 5. Attempt to access the disk Actual results: Disk reads fail. When inspecting the generated domain XML, it looks like this: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/vmdata/disk.qcow2' index='1'/> <backingStore type='file' index='2'> <format type='raw'/> <source file='/vmdata/backing.qcow2'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </disk> Note the "raw" format of the backing store, which is wrong. Expected results: This used to work fine. It used to autodetect that the backing store was qcow2 not raw. Additional info: Manually changing the XML to specify qcow2 format for the backing file works around the problem, but previously this was not necessary.
(In reply to Ben Swartzlander from comment #0) > Description of problem: > When creating a libvirt domain using XML, it used to be possible to specify > a disk which was a qcow2 file that was backed by another qcow2 file, simply > by pointing to the top qcow2 file, and libvirt would figure out what to do. The main problem is that the top level image does not record the format of the backing file. This is specified using the -F swithc for qemu-img create. > Now, if I do this, it mistakenly marks the format backing file as "raw" > instead of "qcow2", redering the virtual disk unreadable. Libvirt always treated the disk as raw in such configuration couldn't tell qemu to treat it as raw. This became possible recently and libvirt started to use this new syntax. This means that such configuration broke. I agree that it's somewhat unexpected. This was discussed in the following places if you want to read up on the rationale: https://www.redhat.com/archives/libvir-list/2020-January/msg00320.html https://bugzilla.redhat.com/show_bug.cgi?id=1588373 https://libvirt.org/kbase/backing_chains.html#vm-refuses-to-start-due-to-misconfigured-backing-store-format The fix for the issue is that libvirt forbids to start the VM if the image format is not recorded in the overlay image starting from 6.0 along with a message outlining how to fix it: commit 0604b9e627168b4a08bfb2e2fa720512f32608b9 Author: Peter Krempa <pkrempa> Date: Fri Jan 10 12:28:19 2020 +0100 news: Mention problems with backing image format probing commit 30867fb098a5f3d6704696d79bc587085a488cf8 Author: Peter Krempa <pkrempa> Date: Fri Jan 10 12:27:07 2020 +0100 util: storage: Link to knowledge base when reporting missing image backing format Mention the knowledge base article which has tips how to fix the backing chain to work with current libvirt. commit 3615e8b39badf2a526996a69dc91a92b04cf262e Author: Peter Krempa <pkrempa> Date: Tue Dec 17 17:04:04 2019 +0100 util: storage: Don't treat files with missing backing store format as 'raw' Assuming that the backing image format is raw is wrong when doing image detection: 1) In -drive mode qemu will still probe the image format of the backing image. This means it will try to open a backing file of the image which will fail if a more advanced security model is in use. 2) In blockdev mode the image will be opened as raw actually which is wrong since it might be qcow. Not opening the backing images will also end up in the guest seeing corrupted data. Rather than attempt to solve various corner cases when us assuming the storage file being raw and actually being right forbid startup when the guest image doesn't have the format specified in the metadata. https://bugzilla.redhat.com/show_bug.cgi?id=1588373 *** This bug has been marked as a duplicate of bug 1588373 ***
there are two more things you could do to soften this incompatible change: 1. add a BIG FAT WARNING to qemu-img 2. give a recipe here on how to fix qcow2 images created without `-F` option.
The second one is fixed already (starting from libvirt-6.0): 1: libvirt now reports an error for any misconfigured backing image 2: https://libvirt.org/kbase/backing_chains.html#vm-refuses-to-start-due-to-misconfigured-backing-store-format 3: the above link is mentioned in the error message libvirt emits when it finds wrongly configured backing chain
Ah! yes, thanks, Peter.