[libvirt] [PATCH 2/2] storage: Check qemu-img encryption type capability

[Daniel P. Berrangé]

On Wed, Apr 18, 2018 at 08:08:41AM -0400, John Ferlan wrote:
> 
> 
> On 04/18/2018 04:29 AM, Daniel P. Berrangé wrote:
> > On Tue, Apr 17, 2018 at 03:23:33PM -0400, John Ferlan wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1526382
> >>
> >> As of QEMU 2.9, qemu-img has enforced using the "key-secret" for
> >> creation of encrypted volumes. That is, LUKS encryption is now
> >> required and the old (awful) qcow[2] encryption methodolgy is
> >> no longer supported.
> > 
> > Not quite right actually. The 'key-secret' approach can be used to
> > create both LUKS and the old qcow[2] encryption.
> > 
> > We only forbid  qcow[2] encryption with the system emulators, still
> > have full support in qemu-img for sake of interoperability. The only
> > break there was the command line syntax
> > 
> 
> Oh, OK - well I didn't find that to be obvious... So there is a way
> using secret objects to create a qcow[2] encrypted volume?

Sure, the exact same syntax as with luks volumes - you just specify
"qcow" instead of "luks" as the type.

> Still Jano has NACK'd using help scraping (and posted a separate series
> removing it completely).
> 
> So then the question becomes does this change "convert" into a disallow
> this type of creation going forward? Do we just cause failure in
> storageBackendCreateQemuImgCheckEncryption when not using LUKS or do we
> let the qemu-img just be the bad guy and do nothing in our code?

QEMU is likely to support the qcow2 enc format indefinitely, but only
in the qemu-img tool for the sake of data liberation. I don't think
libvirt should arbitrarily decide to drop it from our qemu-img
usage.


> >> +        if (imgformat >= QEMU_IMG_BACKING_FORMAT_OPTIONS_KEY_SECRET) {
> >> +            virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> >> +                           _("qemu-img no longer supports qcow encryption, "
> >> +                             "use LUKS encryption instead"));
> >> +            return -1;
> >> +        }
> > 
> > Why is  imgformat being compared against QEMU_IMG_BACKING_FORMAT_OPTIONS_KEY_SECRET ?
> > 
> > Aren't those two sides of the expression from completely different
> > enum types.
> > 
> 
> Although perhaps not well named, @imgformat is fetched via
> virStorageBackendQEMUImgBackingFormat which returns
> QEMU_IMG_BACKING_FORMAT_OPTIONS* type enum's.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|