Differences to RFC: http://www.redhat.com/archives/libvir-list/2016-March/msg00966.html (many, but highlights are): * Patch2 is Patch1 and I figured out the 'qom-list-types' magic in order to fill in the .replies file * Use of qemuDomainObjPrivate rather than passing 'masterKey' * The masterKey is not stored in XML output nor is it stored as a base64 value * The masterKey is created during qemuProcessPrepareHost right after the libDir is created. It is only created if the capability exists. * The masterKey is removed during qemuProcessStop. There is no call to qemuDomainMasterKeyRemove from qemuDomainObjPrivateFree since the assumption is the *Stop code will handle things. * Created a qemuDomainMasterKeyReadFile to handle reading the master.key file during qemuProcessReconnect rather than the prior code which would have taken the masterKey from the XML file in base64 format. * The MasterKeyCreate and MasterKeyRemove incorporate the file manipulation as well. The *Create code will save the base64 encoded secret. The callers need only call those API's. * The masterKey is generated using gnutls_rnd if that's available (following examples w/ HAVE_GNUTLS_CRYPTO_H); otherwise, the fallback position is the virRandomBits. * Moved alias code to qemu_alias.c instead of qemu_domain.c. Notes on comments where I didn't change things: * Since qemuBuildCommandLine doesn't get the qemuDomainObjPrivate, I kept the qemuBuildHasMasterKey checking the capability bit only. Other *CommandLine callers would use the same decision point. If the key was available, then "assume" it's already present on the command line since there's no failure path from building the master key command line. * I kept the write "0" to the key file just before deletion. I wasn't sure with file caches being as they can be if there could ever be that 100% guarantee that what was unlink()'d really "went away" completely. Something I noted and wasn't "clear" how to resolve, so I followed existing practices of not checking if something exists: * The recent changes to have a qemuProcessCreatePretendCmd which will allow libDir and channelTargetDir creation using "/tmp/", but not actually creating the directory inhibit this code from being able to check if the path to the masterKey exists before sending it to qemu. Now if the 'flags' was passed to qemuBuildCommandLine and the VIR_QEMU_PROCESS_START_PRETEND could be checked while building the MasterKey command line, then I could have the check in. Otherwise, I just have to assume everything's worked "right" up to this point. A secondary note on that... Why "/tmp/" - shouldn't have been "tmp/"? John Ferlan (3): qemu: Add capability bit for qemu secret object qemu: Create domain master key qemu: Introduce qemuBuildMasterKeyCommandLine src/qemu/qemu_alias.c | 17 ++ src/qemu/qemu_alias.h | 3 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 68 ++++++ src/qemu/qemu_domain.c | 269 +++++++++++++++++++++ src/qemu/qemu_domain.h | 13 + src/qemu/qemu_process.c | 11 + tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.6.0-1.replies | 3 + .../qemuxml2argvdata/qemuxml2argv-master-key.args | 23 ++ tests/qemuxml2argvdata/qemuxml2argv-master-key.xml | 30 +++ tests/qemuxml2argvtest.c | 2 + 13 files changed, 443 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-master-key.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-master-key.xml -- 2.5.0 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list