Connecting to a remote Libvirt instance on Ubuntu 12.04 (libvirt 0.9.8) via, e.g., virsh -c qemu+tls://hostname.example.com/system simply hangs. I have to terminate virsh with Ctrl+C to get my terminal back.
Connecting to the same remote Libvirt instance via unencrypted TCP (qemu+tcp) or via SSH (qemu+ssh) works. Connecting to a different Libvirt instance on Ubuntu 10.04 from the same client machine as above via qemu+tls works fine, too. So this looks like a regression to me, if that term applies here.
What is interesting is that the remote connection via qemu+tls to the problematic Libvirt instance *works* in many cases when I run strace on the daemon process AND the strace output goes to stdout. Could this indicate a race condition somewhere in the Libvirt (or TLS/SSL) code? Seeing as tracing system calls and printing them to stdout generally and noticeably impacts performance?
I will attach debug logs from the problematic remote Libvirt daemon as well as strace outputs, one of each where the connection worked (thanks to the strace voodoo) and one of each where the connection hung (hanged?).
In the "hang" debug logs there is a line "authentication failed: TLS handshake failed A TLS packet with unexpected length was received." This indicates my pressing Ctrl+C on the remote client side (terminating the hanging virsh process). In the "works" debug logs there is also one such line, which indicates one connection attempt failed in the described manner, but after it follows a connection attempt that worked. As I said, the strace voodoo makes *most* connection attempts work, but not all. Again, this indicates to me some kind of race condition somewhere.
Please let me know what I can do to debug and test this further.
Thanks. In your case, is the client also 12.04? An incompatibility between oneiric guests and precise hosts has been reported recently (hence marking this confirmed). If precise guests also cause a problem, that is new to me and good to know.