[...]
>> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
