[libvirt] backing file chains, -blockdev, and storage file autodetection

[Martin Wilck]

On Thu, 2020-01-09 at 14:34 +0000, Daniel P. Berrangé wrote:
> 
> IIUC there are three scenarios at play here
> 
>  1. qcow2 file, first level raw backing
>  2. qcow2 file, first level qcow2 backing, no  backing
>  3. qcow2 file, first level qcow2 backing, with second level backing
> 
> Historically with the SELinux driver, if no backing_fmt is set,
> then we blindly assume that scenario (1) is in effect.
> 
> We cannot tell QEMU that we treated it as scenario (1) though,
> so QEMU will still probe format and potentially open the
> first level backing as qcow2 still.
> 
> IOW, despite our SELinux & QEMU driver assumption for scenario (1),
> scenario (2) would still suceed in the past.  Scenario (3) would
> always have failed, because SELinux won't have labelled the second
> level backing.

But it only failed with SELinux, right? Not every distro is mandating
SELinux usage with libvirt. SUSE distros don't, for example.

> Essentially scenario (2) worked by accident, not design, but
> IIUC we have not been warning users about this.
> 
> With new libvirt and -blockdev we still assume the backing_fmt
> is raw if not set in the SELinux driver, but we now have the
> ability to tell QEMU about our assumption via -blockdev. As
> such we've not ensured scenario (2) fails.
> 
> 
> Users who were silently relying on scenario (2) are now broken
> and have three options IIUC
> 
>  - Run qemu-img rebase to set the backing_fmt
> 
> or
> 
>  - Update the guest XML to set the <backingStore> format value
> 
> or
> 
>  - Update the /etc/libvirt/qemu.conf to set capability_filters
>    to disable "blockdev"

I wasn't aware of this option, thanks. I'd actually looked for
a way to revert libvirt's behavior to what it did in previous versions.

> Always assuming the format is raw certainly avoids the security
> danger, but is unhelpful to users who relied on scenario (2).
> 
> I'm inclined to say we should make scenario (2)/(3) into a hard
> error. Only allow scenario (1) to run normally.
> 
> ie, we should probe the disk format for the backing file, and
> if it is *not* raw, then report an immediate error, with the
> error message pointing to the kbase page explaining how to
> fix this. This will help the 99% common case identify the
> fix more quickly, with no obvious downside that I see.

Sounds good. I'd appreciate mention of the capability_filters option on
the kbase page. 

Thanks,
Martin


-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE  Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix
Imendörffer