[PATCH v4 4/5] qemu: add librbd encryption engine

Peter Krempa pkrempa at redhat.com
Thu Oct 21 12:07:53 UTC 2021


On Thu, Oct 21, 2021 at 11:40:20 +0000, Or Ozeri wrote:
>    Thanks for reviewing all of my patches!
>    I'm fine with you making any of the changes you suggested.
>    So the only change I need to make is "specify what's happening in the
>    storage driver"?
>    Can you elaborate what do you mean by that?
>    I can add something like:
>    For librbd engine, the encryption happens inside the librbd storage
>    driver, so block read/write requests coming in from the hypervisor (qemu)
>    are plaintext,
>    but encrypted by the storage driver before being persisted.
>    Is this the kind of thing you were thinking about?

I meant the libvirt storage driver, which provides the storage
pool/volume functionality.

The code in the storage driver can create encrypted qcow2 images. (not
on RBD IIRC), but is using qemu-img to do that, which doesn't use the
same code we use in the qemu driver to instantiate VMs.

So while qemu-img could use the librbd encryption engine, the storage
driver code can't control it in such way.

Similarly the code doesn't share the 'qemu' validation/post-parse checks
so the librbd and luks2 combinations are not rejected.




More information about the libvir-list mailing list