[libvirt] backing file chains, -blockdev, and storage file autodetection
Martin Wilck
Martin.Wilck at suse.com
Thu Jan 9 14:47:22 UTC 2020
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
More information about the libvir-list
mailing list