[libvirt] Libvirt 0.9.4rc2 + qemu 0.15 VNC/TLS not working

Hi all, I am trying new versions of software for my libvirt/qemu farm. I upgraded libvirt to 0.9.3 and I had problems with loading certificates for libvirt itself (probably GNUTLS related). Upgrade to 0.9.4rc2 solved the problem. Now I am trying to upgrade qemu (from 0.12.5) to 0.15. I compiled the SRPM from rawhide for Fedora 13 (OS on my farms) and I copied the binary to one farm, so I can choose qemu version by <emulator> element in guest XML. I had problem with booting off virtio disk, but upgrade of seabios to 0.6.2 solved it (I had to make a wrapper for qemu to be able to add -bios option though). But main issue that I am not able to solve is that VNC is not using TLS. I've found out these: * qemu 0.12.5 is working without problems * there is no error in libvirt or qemu machine log * If I copy the command from libvirt log, remove the network and monitor definition and start it under root, TLS works as expected * the vnc definition on command line is quite simple: -vnc 0.0.0.0:0,password,tls,x509=/etc/pki/libvirt/pki-vnc -k en-us I am thinking whether there is not a problem with monitor setting something after the machine starts. Libvirt does the same with password, so maybe it does something with TLS. Unfortunately I do not know whether there is any option how to debug the monitor libvirt<->qemu communication. And I have one other question. Is there any way how to interact directly with monitor? Qemu has new guest agent that seems to provide some nice functions and expose them via monitor and I would like to test it. Radek

Dne 23.8.2011 14:36, Radek Hladik napsal(a):
I am thinking whether there is not a problem with monitor setting something after the machine starts. Libvirt does the same with password, so maybe it does something with TLS
I tried to remove the VNC password from guest XML and TLS is working. So actually now the situation is like this: * guest with password+qemu configured to use TLS = no TLS (VNC AUTH TYPE=2) * guest without password+qemu configured to use TLS = working TLS (VNC AUTH TYPE=19) I hope it will help to make my issue more clear. I am really suspecting that the password setup somehow removes the TLS option from VNC. Radek

On Tue, Aug 23, 2011 at 08:50:35PM +0200, Radek Hladik wrote:
Dne 23.8.2011 14:36, Radek Hladik napsal(a):
I am thinking whether there is not a problem with monitor setting something after the machine starts. Libvirt does the same with password, so maybe it does something with TLS
I tried to remove the VNC password from guest XML and TLS is working. So actually now the situation is like this:
* guest with password+qemu configured to use TLS = no TLS (VNC AUTH TYPE=2)
* guest without password+qemu configured to use TLS = working TLS (VNC AUTH TYPE=19)
I hope it will help to make my issue more clear. I am really suspecting that the password setup somehow removes the TLS option from VNC.
Yes, QEMU applied a broken fix for CVE-2011-0011 which means whenever you set a password, they reset auth type to 'VNC' (type=2). http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02795.html Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

Dne 24.8.2011 13:55, Daniel P. Berrange napsal(a):
On Tue, Aug 23, 2011 at 08:50:35PM +0200, Radek Hladik wrote:
Dne 23.8.2011 14:36, Radek Hladik napsal(a):
I am thinking whether there is not a problem with monitor setting something after the machine starts. Libvirt does the same with password, so maybe it does something with TLS
I tried to remove the VNC password from guest XML and TLS is working. So actually now the situation is like this:
* guest with password+qemu configured to use TLS = no TLS (VNC AUTH TYPE=2)
* guest without password+qemu configured to use TLS = working TLS (VNC AUTH TYPE=19)
I hope it will help to make my issue more clear. I am really suspecting that the password setup somehow removes the TLS option from VNC.
Yes, QEMU applied a broken fix for CVE-2011-0011 which means whenever you set a password, they reset auth type to 'VNC' (type=2).
http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02795.html
Regards, Daniel
Thanks for your answer. I tried to comment out vs->auth = VNC_AUTH_VNC; inspired by your patch (the whole patch did not work with my version of qemu ) and it fixed the issue. I will check how the situation will evolve, whether qemu developers will fix it or not. Radek
participants (3)
-
Daniel P. Berrange
-
Radek Hladik
-
Radek Hladik