[libvirt] [PATCH v9 3/4] qemu: Introduce qemuDomainPrepareDiskSource

John Ferlan jferlan at redhat.com
Wed Sep 27 14:49:27 UTC 2017



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 at redhat.com>
>> ---
>>  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.
> 




More information about the libvir-list mailing list