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

[Daniel P. Berrangé]

On Wed, Apr 18, 2018 at 08:53:09AM -0400, John Ferlan wrote:
> 
> 
> On 04/18/2018 08:17 AM, Daniel P. Berrangé wrote:
> > 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.
> > 
> 
> So that means Jano's series to remove help scraping completely cannot be
> applied since this code would need to check that the option exists
> before using it; otherwise, anything inclusive of QEMU 1.5 and 2.9 would
> fail (the option was introduced in 2.10 - I mistyped above).

Yes & no - some of the stuff Jano is killing can be assumed to be
present in 1.5.0 or newer, so that is fine.

QEMU has never provided any way to probe capabilities for qemu-img
though. For new features that never existed we can blindly invoke
qmeu-img and let it report errors itself.  We only get a problem
for features where the implementation changed.  In such cases we
have choice of only supporting 1 approach, or doing help scraping
or doing version number scraping, all of which suck.

In the particular case only, I suggest we say to hell with back
compat and just pick the new "secrets" based approach which works
with qcow2 built-in crap encryption for QEMU >= 2.6. The number
of users who'll be hurt by this will be essentially nil.

We might find we need to re-introduce help scraping in future for
other reasons, but lets not worry about it now

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 :|