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@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. */
+ if (src->type == VIR_STORAGE_TYPE_NETWORK &&
+ src->protocol == VIR_STORAGE_NET_PROTOCOL_VXHS) {
+
+ if (src->haveTLS == VIR_TRISTATE_BOOL_ABSENT) {
+ if (cfg->vxhsTLS)
+ src->haveTLS = VIR_TRISTATE_BOOL_YES;
+ else
+ src->haveTLS = VIR_TRISTATE_BOOL_NO;
+ src->tlsFromConfig = true;
+ }
+
+ if (src->haveTLS == VIR_TRISTATE_BOOL_YES) {
+ if (!diskAlias) {
+ virReportError(VIR_ERR_INVALID_ARG, "%s",
+ _("disk does not have an alias"));
+ return -1;
+ }
+
+ /* Grab the vxhsTLSx509certdir and set the verify/listen values.
+ * NB: tlsAlias filled in during qemuDomainGetTLSObjects. */
+ if (VIR_STRDUP(src->tlsCertdir, cfg->vxhsTLSx509certdir) < 0)
+ return -1;
+
+ src->tlsListen = false;
+ src->tlsVerify = true;
+ }
+ }
+
+ return 0;
+}
+
+
+/* qemuProcessPrepareDiskSource:
+ * @def: live domain definition
+ * @driver: qemu driver
+ *
+ * Returns 0 on success, -1 on failure
+ */
+int
+qemuDomainPrepareDiskSource(virDomainDefPtr def,
+ virQEMUDriverConfigPtr cfg)
+{
+ size_t i;
+
+ for (i = 0; i < def->ndisks; i++) {
+ if (qemuDomainPrepareDiskSourceTLS(def->disks[i]->src,
+ def->disks[i]->info.alias,
+ cfg) < 0)
+ return -1;
+ }
+
+ return 0;
+}
+
int
qemuDomainPrepareShmemChardev(virDomainShmemDefPtr shmem)
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index b291dc308..93db23c2b 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -864,6 +864,17 @@ void qemuDomainPrepareChardevSource(virDomainDefPtr def,
virQEMUDriverConfigPtr cfg)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
+int
+qemuDomainPrepareDiskSourceTLS(virStorageSourcePtr src,
+ const char *diskAlias,
+ virQEMUDriverConfigPtr cfg)
+ ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(3);
+
+int
+qemuDomainPrepareDiskSource(virDomainDefPtr def,
+ virQEMUDriverConfigPtr cfg)
+ ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
+
int qemuDomainPrepareShmemChardev(virDomainShmemDefPtr shmem)
ATTRIBUTE_NONNULL(1);
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index e6cc41e13..c3a1db497 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5357,6 +5357,10 @@ qemuProcessPrepareDomain(virConnectPtr conn,
if (qemuDomainMasterKeyCreate(vm) < 0)
goto cleanup;
+ VIR_DEBUG("Prepare disk source backends for TLS");
+ if (qemuDomainPrepareDiskSource(vm->def, cfg) < 0)
+ goto cleanup;
+
VIR_DEBUG("Prepare chardev source backends for TLS");
qemuDomainPrepareChardevSource(vm->def, cfg);
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 35f468e35..95028e55b 100644
--- a/src/util/virstoragefile.c
+++ b/src/util/virstoragefile.c
@@ -2041,6 +2041,8 @@ virStorageSourceCopy(const virStorageSource *src,
ret->shared = src->shared;
ret->haveTLS = src->haveTLS;
ret->tlsFromConfig = src->tlsFromConfig;
+ ret->tlsListen = src->tlsListen;
+ ret->tlsVerify = src->tlsVerify;
/* storage driver metadata are not copied */
ret->drv = NULL;
@@ -2054,7 +2056,9 @@ virStorageSourceCopy(const virStorageSource *src,
VIR_STRDUP(ret->configFile, src->configFile) < 0 ||
VIR_STRDUP(ret->nodeformat, src->nodeformat) < 0 ||
VIR_STRDUP(ret->nodestorage, src->nodestorage) < 0 ||
- VIR_STRDUP(ret->compat, src->compat) < 0)
+ VIR_STRDUP(ret->compat, src->compat) < 0 ||
+ VIR_STRDUP(ret->tlsAlias, src->tlsAlias) < 0 ||
+ VIR_STRDUP(ret->tlsCertdir, src->tlsCertdir) < 0)
goto error;
if (src->nhosts) {
@@ -2279,6 +2283,9 @@ virStorageSourceClear(virStorageSourcePtr def)
virStorageSourceBackingStoreClear(def);
+ VIR_FREE(def->tlsAlias);
+ VIR_FREE(def->tlsCertdir);
+
memset(def, 0, sizeof(*def));
}
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;
+ bool tlsVerify;
};
--
2.13.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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@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.
[...]
> 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.
> + bool tlsVerify;
Rest looks okay, so ACK if you drop the 'listen' attribute.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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@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.
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.