Hey,
I recently setup ovirt/vdsm on one of my boxes. For some reason spice TLS
was disabled through spice_tls = no in /etc/libvirt/qemu.conf.
Then I created a VM, started it, and had troubles connecting to it with
spicec. After investigating (thanks djasa), I realized that qemu was
started with some encrypted SPICE channels but with no TLS port configured,
which explained why I couldn't connect.
https://bugzilla.redhat.com/show_bug.cgi?id=790436 was filed against
libvirt about this, but now we are wondering how to best fix things in
libvirt.
What is currently happening is that libvirt doesn't warn when a domain has
<channel name='main' mode='secure'/> with spice_tls = no in
qemu.conf, and
it adds the corresponding tls-channel=main to qemu command-line, but
doesn't set a TLS port (if one is set it's silently ignored).
There are at least two ways of solving this problem in libvirt:
* either the current behaviour is kept, but "tls-channel=main" is not
added to qemu command line when spice-tls is disabled. The drawback of
this is that some security options that have been explicitly set in the
domain XML are silently ignored
* or the current behaviour is changed, and in this situation (SPICE secure
channels in the XML, but TLS disabled in qemu.conf), libvirt errors out,
which would change the current behaviour.
This has been discussed on the libvirt mailing list (cc'ed) in this thread:
https://www.redhat.com/archives/libvir-list/2012-February/msg00656.html
Before making a decision, we were wondering what behaviour oVirt
would expect in this case (error or silently ignoring the secure channels),
and if a setup with spice_tls = no in /etc/libvirt/qemu.conf is something
widely deployed that you have to support, or if it's more of an
experimental feature at this point.
Thanks for any input you can give on this matter,
Christophe
Please note Bug 788092 - VDSM: Disable vdsm's ssl'ability influence
spice ssl'ability and prevent VM from starting