[libvirt-users] Change in treatment of qcow2 with chained backing files in v5.10.0?

[Jens John]

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.