On Tue, Oct 18, 2016 at 06:59:57AM -0400, John Ferlan wrote:
> On 10/18/2016 02:27 AM, Pavel Hrdina wrote:
> >> "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."
> > Don't forget this part of the same review:
> > "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"
> > That also means to override chardev_tls = "0" by "tls='yes'".
> If the default cfg behaviour is "1", then that tells us "someone" has
> set up the TLS environment and thus the domain/chardev override would be
> If the default cfg behaviour is "0", then that means we cannot guarantee
> the environment necessary has been set up and we cannot allow the
> domain/chardev setting to enable TLS.
We have two separate tasks at the host level
- Setup of TLS certificates (ie put the PEM files in the right places)
- Global default for use of TLS by chardevs
We only have a config option in qemu.conf for the latter. ie if
chardev_tls=1, this is implicitly saying that TLS certs are deployed
in right place. IIUC, you're saying that if chardev_tls=0, then we
should interpret that to meant TLS certs are *not* deployed.
Pavel is saying that if chardev_tls=0 in qemu.conf, and tls=1 in the
XML, then we should assume that TLS certs *are* deployed on the host
in the right place. I think this is not unreasonable - we can easily
check to see if the certs exist on disk in this case.
IOW, I agree that we should have a tri-state at the XML level
- no tls attribute in XML - honour chardev_tls from qemu.conf
- tls=1 in XML, then turn on TLS
- tls=0 in XML, then don't use TLS
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
libvir-list mailing list