Hello Peter, thank you for replying in such detail. On Tue, Dec 17, 2019 at 11:22:52AM +0100, Peter Krempa wrote:
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.
You're right. My backing files are missing the 'backing file format' field: image: windows7-base.qcow2 file format: qcow2 virtual size: 50 GiB (53687091200 bytes) disk size: 7.37 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: windows7-Office2013.qcow2 file format: qcow2 virtual size: 75 GiB (80530636800 bytes) disk size: 50.4 GiB cluster_size: 65536 backing file: windows7-taintable.qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: windows7-taintable.qcow2 file format: qcow2 virtual size: 50 GiB (53687091200 bytes) disk size: 7.88 GiB cluster_size: 65536 backing file: windows7-base.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.
Understood. So in order to load an image or backing file, qemu/libvirt expects the format to be explicitly defined whenever a 'next image' is being referenced.
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.
Correct. I'm using neither selinux nor apparmor.
(...) So as a first thing you should create the images properly. that when you are creating the overlay image, you have to use the '-F' parameter of qemu-img create. (...)
Fixed the issue successfully using qemu-img rebase.
(...) (Note that snapshots/overlays created by libvirt always do this). (...)
It's probably clear by now but these images were created manually, many years ago.
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.
I agree that failing in a clear way would indeed help the user, though now that I know what I'm looking for, it's also clear from the -blockdev argument what's going on. Thanks, again, for your time, Jens.