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

Hi, On Tue, Feb 21, 2012 at 06:09:06PM +0200, Dan Kenigsberg wrote: > Please note Bug 788092 - VDSM: Disable vdsm's ssl'ability influence > spice ssl'ability and prevent VM from starting > https://bugzilla.redhat.com/show_bug.cgi?id=788092#c1 > > Could it be that you have ssl=false in your vdsm.conf? I've got ssl=true in my vdsm.conf, and the VM starts properly (qemu is running after I start it in the web interface) so it's probably a slightly different issue I'm hitting.

From Vdsm's point of view, it would be nice if libvirt/qemu protected us