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