On 09/27/2017 09:21 AM, Peter Krempa wrote:
> On Tue, Sep 19, 2017 at 21:32:45 -0400, John Ferlan wrote:
>> Introduce a function to setup any TLS needs for a disk source.
>>
>> If there's a configuration or other error setting up the disk source
>> for TLS, then cause the domain startup to fail.
>>
>> For VxHS, follow the chardevTLS model where if the src->haveTLS hasn't
>> been configured, then take the system/global cfg->haveTLS setting for
>> the storage source *and* mark that we've done so via the tlsFromConfig
>> setting in storage source.
>>
>> Next, if we are using TLS, then generate an alias into a virStorageSource
>> 'tlsAlias' field that will be used to create the TLS object and added to
>> the disk object in order to link the two together for QEMU.
>>
>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
>> ---
>> src/qemu/qemu_domain.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++
>> src/qemu/qemu_domain.h | 11 +++++++
>> src/qemu/qemu_process.c | 4 +++
>> src/util/virstoragefile.c | 9 +++++-
>> src/util/virstoragefile.h | 8 ++++++
>> 5 files changed, 104 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
>> index 50b536eec..8080b7fb1 100644
>> --- a/src/qemu/qemu_domain.c
>> +++ b/src/qemu/qemu_domain.c
>> @@ -7601,6 +7601,79 @@ qemuDomainPrepareChardevSource(virDomainDefPtr def,
>> }
>>
>>
>> +/* qemuProcessPrepareDiskSourceTLS:
>> + * @source: pointer to host interface data for disk device
>> + * @diskAlias: alias use for the disk device
>> + * @cfg: driver configuration
>> + *
>> + * Updates host interface TLS encryption setting based on qemu.conf
>> + * for disk devices. This will be presented as "tls='yes|no'" in
>> + * live XML of a guest.
>> + *
>> + * Returns 0 on success, -1 on bad config/failure
>> + */
>> +int
>> +qemuDomainPrepareDiskSourceTLS(virStorageSourcePtr src,
>> + const char *diskAlias,
>> + virQEMUDriverConfigPtr cfg)
>> +{
>> +
>> + /* VxHS doesn't utilize a password protected server certificate,
>> + * so no need to add a secinfo for a secret UUID. */
>
> It's a client certificate. Is there a technical limitation in the qemu
> VxHS driver for not supporting encrypted certificates? AFAIK it should
> use the standard x509 impl so this looks like a libvirt impl. limitation
> only.
>
AFAIU - the server side is handled by libqnio which would have the
server TLS certificate. The libqnio isn't part of QEMU - it some sort of
separate entity. Truly, libvirt and qemu are both just clients in this
environment.
> [...]
>
>> diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h
>> index 4817090fc..28cc718a4 100644
>> --- a/src/util/virstoragefile.h
>> +++ b/src/util/virstoragefile.h
>> @@ -288,6 +288,14 @@ struct _virStorageSource {
>> /* Indication whether the haveTLS value was altered due to qemu.conf
>> * setting when haveTLS is missing from the domain config file */
>> bool tlsFromConfig;
>> +
>> + /* If TLS is used, then mgmt of the TLS credentials occurs via an
>> + * object that is generated using a specific alias for a specific
>> + * certificate directory with listen and verify bools. */
>> + char *tlsAlias;
>> + char *tlsCertdir;
>> + bool tlsListen;
>
> I think you inspired yourself too much in the chardev section. 'listen'
> does not make much sense with disks.
>
OK - right... These would all be clients I suppose, so no use.
Tks
John
>
>> + bool tlsVerify;
>
> Rest looks okay, so ACK if you drop the 'listen' attribute.
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
