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(a)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 :|