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. Likewise someone can modify only qemu.conf without preparing certificates and the domain would fail to start. Libvirt cannot guarantee that the environment is configured in any case. So if someone doesn't setup the environment and uses "tls='yes'" libvirt will print sane error message from qemu that the certificate files doesn't exist. Pavel
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list