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

[...] So I've been working on doing as suggested, there's slight differences for qcow: 1. Usage of "encrypt.key-secret" instead of just "key-secret" 2. Usage of "encrypt.format=aes" (or qcow works too) instead of "encryption=on" 3. Don't need change the "type" value like is done for "luks" in virStorageBackendCreateQemuImgCmdFromVol. The result is (testing mode only): qemu-img create -f qcow2 \ --object secret,id=x0,format=raw,data=letmein \ -o encrypt.format=aes,encrypt.key-secret=x0 \ x0.img 1048576K NB: Using "-b /dev/null" and ",backing_fmt=raw" works just fine as would usage of other -o options such as "compat=1.1,", "compat=0.10", "lazy_refcounts,", and "preallocation={off|metadata|falloc|full}". So far, so good. However, storagevolxml2argvtest.c also generates qemu-img convert options. And this is where things go down hill. The former commands would for example do: qemu-img convert -f raw -O qcow2 -o encryption=on \ /var/lib/libvirt/images/sparse.img /var/lib/libvirt/images/OtherDemo.img which in the new syntax would conceivably be: qemu-img convert -f raw -O qcow2 \ --object secret,id=OtherDemo.img_encrypt0,file=/path/to/secretFile \ -o encrypt.format=aes,encrypt.key-secret=OtherDemo.img_encrypt0 \ /var/lib/libvirt/images/sparse.img \ /var/lib/libvirt/images/OtherDemo.img But, testing that type of model in practice: qemu-img --version qemu-img version 2.11.93 (v2.12.0-rc4) rm x0.img dd if=/dev/zero of=x0.img bs=1M seek=10 count=0 ls -al x0.img -rw-r--r--. 1 root root 10485760 Apr 19 12:34 x0.img qemu-img convert -f raw -O qcow2 \ --object secret,id=x,format=raw,data=letmein \ -o encrypt.key-secret=x,encrypt.format=aes \ x0.img x1.img qemu-img: Could not open 'x1.img': Parameter 'encrypt.key-secret' is required for cipher NB: The x1.img file does exist: ls -al x1.img -rw-r--r--. 1 root root 196616 Apr 19 12:45 x1.img FWIW: A similar setup to convert to luks also fails: qemu-img convert -f raw -O luks \ --object secret,id=x,format=raw,data=letmein \ -o key-secret=x \ x0.img x1.img qemu-img: Could not open 'x1.img': Parameter 'key-secret' is required for cipher NB: This command takes longer to fail and like before the x1.img exists: ls -al x1.img -rw-r--r--. 1 root root 12554240 Apr 19 12:46 x1.img It seems perhaps qemu-img is not applying the secrets to the target file, rather it may be using the source file, but reading the qemu-img.c code and figuring out how argument processing works isn't clear to me. So - mainly checking - is this the 'expected' syntax? and secondarily, of course, is this a bug in qemu-img? Tks - John