[libvirt] [PATCH v5 6/9] conf: Add new secret element for tcp chardev

[John Ferlan]

On 08/05/2016 04:25 AM, Daniel P. Berrange wrote:
> On Thu, Aug 04, 2016 at 11:21:24AM -0400, John Ferlan wrote:
>> Define, parse, and format a key secret element for a chardev tcp backend.
>> This secret will be used in conjunction with the chartcp_tls_x509_cert_dir
>> in order to provide the secret to the TLS encrypted TCP chardev.
>>
>>     <secret type='tls' usage='tlsexample'/>
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>>  docs/formatdomain.html.in                          | 29 ++++++++++++
>>  docs/schemas/domaincommon.rng                      | 21 +++++++++
>>  src/conf/domain_conf.c                             | 35 +++++++++++++++
>>  src/conf/domain_conf.h                             |  3 ++
>>  ...uxml2argv-serial-tcp-tlsx509-secret-chardev.xml | 51 ++++++++++++++++++++++
>>  ...ml2xmlout-serial-tcp-tlsx509-secret-chardev.xml |  1 +
>>  tests/qemuxml2xmltest.c                            |  1 +
>>  7 files changed, 141 insertions(+)
>>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.xml
>>  create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-secret-chardev.xml
> 
> Hmm, it feels little odd that we're having to give the password in
> the XML, for a certificate thats configured in qemu.conf. I wonder
> if we instead need to have the secret UUID listed in qemu.conf too
> 
> 

I knew there was something I wanted to get back to...

I guess it seemed awkward to have to modify qemu.conf to list a UUID of
a libvirt secret that would be generated after initial startup and thus
would require a restart to read/load the secret into the cfg.

I suppose that's akin to having/changing the "{spice|vnc}_password" in
qemu.conf, so perhaps no different from that processing. Still

Hmmm... I suppose the admin interface could handle these tasks as well.

Anyway - secondarily, by adding UUID to qemu.conf, if cfg->chardevTLS
was set (something I appear to have forgotten to do in patch 2 too,
sigh), then that would mean every domain would use TLS. Is that desired?
Or should there still be some domain XML attribute added to signify the
desire for the domain to use TLS.

Would there ever be a use case where multiple TLS environments would be
set up for different domains with the same host?

Tks -

John