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.
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
