Re: [PATCH] tests: fix I/O test for hosts defaulting to LUKSv2

[Eric Blake]

On 9/27/19 5:11 AM, Daniel P. Berrangé wrote:
> Some distros are now defaulting to LUKS version 2 which QEMU cannot
> process. For our I/O test that validates interoperability between the
> kernel/cryptsetup and QEMU, we need to explicitly ask for version 1
> of the LUKS format.

Ultimately, it would be nice to get LUKS 2 support in qemu too, but 
that's a much bigger job.  This is fine for now.

> Signed-off-by: Daniel P. Berrangé <address@hidden>
> ---
>   tests/qemu-iotests/149     |  2 +-
>   tests/qemu-iotests/149.out | 44 +++++++++++++++++++-------------------
>   2 files changed, 23 insertions(+), 23 deletions(-)

> diff --git a/tests/qemu-iotests/149 b/tests/qemu-iotests/149
> index 4f363f295f..8ab42e94c6 100755
> --- a/tests/qemu-iotests/149
> +++ b/tests/qemu-iotests/149
> @@ -153,7 +153,7 @@ def cryptsetup_format(config):
>   
>       (password, slot) = config.first_password()
>   
> -    args = ["luksFormat"]
> +    args = ["luksFormat", "--type", "luks1"]

On Fedora 29, 'cryptsetup --help | grep -A1 type' shows:
  -M, --type=STRING               Type of device metadata: luks, plain,
                                  loopaes, tcrypt

but that is just 'luks', not 'luks1'.

On CentOS 6 (yeah, I know, not relevenant to qemu any more), --type is 
unsupported.  But I didn't check our other range of supported systems. 
My point, however, is whether this patch needs to be conditionalized 
based on what cryptsetup actually supports.

I could not quickly determine if there is some sort of safe no-op 
'cryptsetup --type=FOO action /safe/device' that can be used to tell if 
--type=FOO is recognized.

Otherwise, this makes sense to me.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org