Re: [libvirt-users] Change in treatment of qcow2 with chained backing files in v5.10.0?
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.