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

[John Ferlan]

[...]

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

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