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/ :|