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@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 :|