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

[John Ferlan]

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).

What could be applied would be the removal of OPTIONS and
OPTIONS_COMPAT, but this new one would need to exist since AFAIK there
is no other way currently to query qemu-img for what it supports.

Going to make for some ugly code...

John

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