On Wed, Sep 27, 2017 at 11:05:01 -0400, John Ferlan wrote:
On 09/27/2017 10:25 AM, Peter Krempa wrote:
On Tue, Sep 19, 2017 at 21:32:46 -0400, John Ferlan wrote:
From: Ashish Mittal <Ashish.Mittal@veritas.com>
Alter qemu command line generation in order to possibly add TLS for a suitably configured domain.
Sample TLS args generated by libvirt -
-object tls-creds-x509,id=objvirtio-disk0_tls0,dir=/etc/pki/qemu,\ endpoint=client,verify-peer=yes \ -drive file.driver=vxhs,file.tls-creds=objvirtio-disk0_tls0,\ file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\ file.server.type=tcp,file.server.host=192.168.0.1,\ file.server.port=9999,format=raw,if=none,\ id=drive-virtio-disk0,cache=none \ -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\ id=virtio-disk0
Update the qemuxml2argvtest with a couple of examples. One for a simple case and the other a bit more complex where multiple VxHS disks are added where at least one uses a VxHS that doesn't require TLS credentials and thus sets the domain disk source attribute "tls = 'no'".
Update the hotplug to be able to handle processing the tlsAlias whether it's to add the TLS object when hotplugging a disk or to remove the TLS object when hot unplugging a disk. The hot plug/unplug code is largely generic, but the addition code does make the VXHS specific checks only because it needs to grab the correct config directory and generate the object as the command line would do.
Signed-off-by: Ashish Mittal <Ashish.Mittal@veritas.com> Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/qemu/qemu_block.c | 8 +++ src/qemu/qemu_command.c | 33 +++++++++ src/qemu/qemu_hotplug.c | 79 ++++++++++++++++++++++ ...-disk-drive-network-tlsx509-multidisk-vxhs.args | 43 ++++++++++++ ...v-disk-drive-network-tlsx509-multidisk-vxhs.xml | 50 ++++++++++++++ ...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 30 ++++++++ tests/qemuxml2argvtest.c | 7 ++ 7 files changed, 250 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.args
[...]
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 7dd6e5fd9..7751a608d 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -156,6 +156,52 @@ qemuDomainPrepareDisk(virQEMUDriverPtr driver,
static int +qemuDomainAddDiskSrcTLSObject(virQEMUDriverPtr driver, + virDomainObjPtr vm, + virStorageSourcePtr src, + const char *srcalias) +{ + int ret = -1; + qemuDomainObjPrivatePtr priv = vm->privateData; + virJSONValuePtr tlsProps = NULL; + + /* NB: Initial implementation doesn't require/use a secret to decrypt + * a server certificate, so there's no need to manage a tlsSecAlias
client certificate
No it's the server certificate (server-key.pem) that needs the secret in order to be decrypted.
I think both can be encrypted. What I wanted to point out is that it does not make sense to refer to the server certificate in terms of disks since they are clients only.