Hey there, I'm experiencing a strange but reproducible bug according to backing chains. I can start my machine from the Baseimage and the first overlay, but any further overlay receives an permission denied on the base image. Following are minimal instructions to reproduce the bug. The "permission denied" Error is misleading. It took me hours to figure that out. - can you rework the error messages around the problematic? - If there are really missing execution rights, name the user who is attemting to use the files - If not, Say something like "backing chain corrupt, try to ..." - How can I use more then one overlay in the backing chain? - Is this bug known and fixed in a newer release? - Can I circumvent the bug? # How to reproduce: ## preparations (creating backing chain) me@VM:/storage$ qemu-img create -f qcow2 Base.img 50G Formatting 'Base.img', fmt=qcow2 size=53687091200 cluster_size=65536 lazy_refcounts=off refcount_bits=16 me@VM:/storage$ qemu-img create -f qcow2 -b Base.img FirstFloor.ovl Formatting 'FirstFloor.ovl', fmt=qcow2 size=53687091200 backing_file=Base.img cluster_size=65536 lazy_refcounts=off refcount_bits=16 me@VM:/storage$ qemu-img create -f qcow2 -b FirstFloor.ovl SecondFloor.ovl Formatting 'SecondFloor.ovl', fmt=qcow2 size=53687091200 backing_file=FirstFloor.ovl cluster_size=65536 lazy_refcounts=off refcount_bits=16 me@VM:/storage$ qemu-img create -f qcow2 -b SecondFloor.ovl Roof.ovl Formatting 'Roof.ovl', fmt=qcow2 size=53687091200 backing_file=SecondFloor.ovl cluster_size=65536 lazy_refcounts=off refcount_bits=16 me@VM:/storage$ mkdir houseBackup me@VM:/storage$ cp Base.img FirstFloor.ovl SecondFloor.ovl Roof.ovl ./houseBackup ## Creating virt-Machine via virtmanager => virt-manager: New Machine -> *.iso (here: ms win 10 1607 Devel Editiion x64) CPU/RAM: default select custom storage: Base.img / FirstFloor.ovl / ... # Results while attempting to start machine (after every attemt the whole files from ./houseBackup are restored) Base.img (ok - Win 10 Installation starting) FirstFloor.ovl (ok - Win 10 Installation starting) SecondFloor.ovl (permission denied -> Base.img) => assumed Bug Roof.ovl (permission denied -> Base.img) => assumed Bug # System informationes **virsh # start MyHouse** error: Failed to start domain MyHouse error: internal error: process exited while connecting to monitor: 2018-06-06T12:55:42.062395Z qemu-system-x86_64: -drive file=/storage/SecondFloor.ovl, format=qcow2,if=none,id=drive-ide0-1-0: Could not open backing file: Could not open backing file: Could not open '/storage/Base.img': Permission denied **version** Compiled against library: libvirt 4.0.0 Using library: libvirt 4.0.0 Using API: QEMU 4.0.0 Running hypervisor: QEMU 2.11.1 Ubuntu 18.04 LTS (Dell Precission Tower 3620) **/etc/libvirt/qemu.conf** (extract) dynamic_ownership = 1 user = "root" group = "root" ** the ownership is changed to root, when the machine is starting** -rw-r--r-- 1 root root 193K Jun 7 09:09 Base.img -rw-r--r-- 1 root root 193K Jun 7 09:09 FirstFloor.ovl -rw-r--r-- 1 root root 193K Jun 7 09:09 Roof.ovl -rw-r--r-- 1 root root 193K Jun 7 09:09 SecondFloor.ovl
When I'm wrapping all the images together with rebase '', then it is working. It does not matter if all the overlays are empty or full of usefull informationes. It still does not work.
You've created the images without specifying backing format (using the -F switch for qemu-img). That way libvirt refuses to look for the backing image of Roof.ovl as it treats the backing image as 'raw' due to security implications. This means that libvirt then does not use the correct security label for anything below Roof.ovl. Specifying the backing file format using -F should fix your problem.
it did it! thx so much! qemu-img create -f qcow2 Base.img 50G qemu-img create -f qcow2 -F qcow2 -b Base.img FirstFloor.ovl qemu-img create -f qcow2 -F qcow2 -b FirstFloor.ovl SecondFloor.ovl qemu-img create -f qcow2 -F qcow2 -b SecondFloor.ovl Roof.ovl => Working! --- But can you tell me how I could figure it out by running a general test? Backingchain is showing noting suspicious. Would it be an idea to make the error message around this topic a bit more user friendly? image: Roof.ovl file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 backing file: SecondFloor.ovl Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: SecondFloor.ovl file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 backing file: FirstFloor.ovl Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: FirstFloor.ovl file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 backing file: Base.img Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: Base.img file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
Well, that's kind of hard to do. The error you've seen is reported by qemu. Due to historical reasons we do not consider this a failure if a backing file does not have the format specified. On the other hand. It probably will become a failure scenario when using -blockdev as if we force the type to 'raw' in the backing chain, qemu will complain loudly. I'll keep this open with a new summary and assign it to myself since I'm working on the -blockdev integration
Thank you for your support! --- for everybody else finding this post. To resolve already existing issues with existing images you can do this: qemu-img rebase -f qcow2 -b Base.img -F qcow2 FirstFloor.ovl qemu-img rebase -f qcow2 -b FirstFloor.ovl -F qcow2 SecondFloor.ovl qemu-img rebase -f qcow2 -b SecondFloor.ovl -F qcow2 Roof.ovl
Upstream fixes that by reporting an error if the format is not recorded in the image. Additionally a document is added on how to fix the images. commit 5949ac0f59b791a7677645360586c7c2a7be6cec Author: Peter Krempa <pkrempa> Date: Tue Dec 17 18:50:18 2019 +0100 kbase: Add document outlining backing chain XML config and troubleshooting Signed-off-by: Peter Krempa <pkrempa> Reviewed-by: Michal Privoznik <mprivozn> 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. v5.10.0-334-g5949ac0f59
*** Bug 1790101 has been marked as a duplicate of this bug. ***
*** Bug 1792911 has been marked as a duplicate of this bug. ***