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.
>
> In order to check for this, we scan the qemu-img -o help options
> looking for "key-secret" and if set, we enforce during the create
> volume processing that the about to be encrypted volume doesn't
> attempt to use the old crufty encryption mechanism.
>
> Signed-off-by: John Ferlan <jferlan(a)redhat.com>
> ---
> src/storage/storage_util.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c
> index 7df52239c2..d2e02a57ca 100644
> --- a/src/storage/storage_util.c
> +++ b/src/storage/storage_util.c
> @@ -797,6 +797,7 @@ storagePloopResize(virStorageVolDefPtr vol,
> enum {
> QEMU_IMG_BACKING_FORMAT_OPTIONS = 0,
> QEMU_IMG_BACKING_FORMAT_OPTIONS_COMPAT,
> + QEMU_IMG_BACKING_FORMAT_OPTIONS_KEY_SECRET,
> };
>
> static char *
> @@ -824,6 +825,14 @@ virStorageBackendQemuImgSupportsCompat(const char
> *output)
> return strstr(output, "\ncompat ");
> }
>
> +
> +static bool
> +virStorageBackendQemuImgRequiresKeySecret(const char *output)
> +{
> + return strstr(output, "key-secret");
> +}
> +
> +
NACK
adding more -help output scraping just for a nicer error message for a
feature noone should be using in the first place is not worth it.
Jano
Fair enough - considering your other series...
As a consumer would you expect an error message for any create using
qcow[2] then?
Or should we just rip out the qcow[2] encryption stuff too?
IDC, either way. It's the delta then between qemu 1.5 and 2.9 to
consider...
John