Dan:
Couple of points I forgot to raise at the meeting:
(1) Libguestfs identifies keys differently from strings in the
generator (Key vs String), but DOESN'T mlock keys into memory.
This is (or *was* -- see below) for a good reason: Because we pass
these keys into the appliance, and because the appliance runs in
regular qemu, there's not much point in going to the trouble in
libguestfs when qemu is just going to spill them to swap anyway.
(2) Libguestfs has historically never supported host-encrypted
devices, eg. encrypted qcow2 files. Mainly because no one has ever
asked for it. With the libvirt backend we ought to be able to support
these.
We could create a transient secret, in which case we would modify
libguestfs to do the necessary mlocking.
Or (perhaps better) we might pass the UUID of the secret to libvirt,
and let libvirt manage the secret entirely. I'm not sure this latter
method will work given that essentially most of the time we are using
the session libvirtd.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
