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

[Daniel P. Berrange]

On Tue, Sep 06, 2016 at 06:29:38PM -0400, John Ferlan wrote:
> 
> 
> 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?

As default behaviour I think it is desirable that we can turn TLS on for
every VM at once - I tend to view it as a host network integration task,
rather than a VM configuration task. Same rationale that we use for TLS
wth VNC/SPICE.

> Or should there still be some domain XML attribute added to signify the
> desire for the domain to use TLS.

There's no reason we can't have a tri-state TLS flag against the chardev
in the XML too, to override the default behaviour of cfg->chardevTLS

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|