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 > "no". > > 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 Regards, Daniel -- |: 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 libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list