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@xxxxxxxxxx>
> >> ---
> >> 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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list