Description of problem: libvirt gives base image (as the argument) to qemu while starting VM Version-Release number of selected component (if applicable): 5.10.0-alt1 How reproducible: ALWAYS Steps to Reproduce: 1. qemu-img create -f qcow2 1.img 100M 2. qemu-img create -f qcow2 -b 1.img 2.img 3. create VM with 2.img as a disk (IDE by default, created with virt-manager) 4. in the VM do "hexdump -C /dev/sda | head" 5. see "QFI...", i.e. the contents of 1.img Actual results: /dev/sda's contents is "QFI...", the contents of 1.img Also the 2.img doesn't seem to show in the VM Expected results: zeroes Additional info: looking into `ps` command output I see that qemu cmdline is weird, containing 1.img as raw image: > /usr/bin/qemu-system-x86_64 \ -name guest=altlinux7,debug-threads=on ... -blockdev {"driver":"file","filename":"/.../tmp/1.img","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-3-format","read-only":true,"driver":"raw","file":"libvirt-3-storage"} -blockdev {"driver":"file","filename":"/.../tmp/2.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"} ...
That is an expected change. You forgot to record the format of the backing image when creating the overlay using the -F switch. This was fixed upstream in 6.0.0 by reporting an explicit error in the above case. You'll need to fix your overlays. You can read up on the rationale here: https://bugzilla.redhat.com/show_bug.cgi?id=1790101#c1 https://www.redhat.com/archives/libvir-list/2020-January/msg00320.html https://bugzilla.redhat.com/show_bug.cgi?id=1588373 An knowledge base article for fixing your images: https://libvirt.org/kbase/backing_chains.html#vm-refuses-to-start-due-to-misconfigured-backing-store-format *** This bug has been marked as a duplicate of bug 1588373 ***