On 06/14/2016 05:39 AM, Daniel P. Berrange wrote:
On Mon, Jun 13, 2016 at 08:40:26PM -0400, John Ferlan wrote:
> Add the domain rng, parse, and format of a new XML element "tlsx509":
>
> <tlsx509 path='/tmp/x509/certdir'/>
>
> The attribute for the element will contain a path to an X.509 certificate
> credential directory to be passed along to the hypervisor to process.
I'm in two minds as to whether we want to add this feature to the XML.
As a point of reference, we don't permit configuration of this for
the VNC / SPICE graphics. In those cases we've defined cert locations
in the qemu.conf file only.
I tend to thing that's probably what we should do for chardevs, nbd
and migration too. Providing certificates to a host is typically
something that you would do when first provisioning the host. As
such you'll almost certainly have a single set of certs you'll use
for all VMs on a given host.
It is an interesting question as to whether you'll use the same set of
certs for VNC, chardev, migration and nbd, or whether each service will
want separate certs. I can see value in both really - particularly if
some of the services are exposed publically (vnc, chardev) while others
are only exposed internally in a mgmt lan (migration, nbd).
I'd suggest we add
chardev_tls_x509_cert_dir
migration_tls_x509_cert_dir
nbd_tls_x509_cert_dir
to let them be configured independantly, but *also* add a
default_tls_x509_cert_dir
if a service specific cert dir config opt is not set, then honour the
default cert dir config opt.
OK - this is certainly an area where I don't have a lot of
experience/insight. My assumption on these bzs was that it could be
possible for different domains on the host to use different certificate
environments based on what they were being used for. Going the route of
qemu.conf file just leads down the path of a singular use/definition per
host.
Thanks for the quick review feedback - it certainly helps!
John