Comment 14 for bug 1001798

After my last comment here over two years ago I haven't had the time and resources to debug this any more than I already had at that point. We have since switched to using unencrypted Libvirt connections (qemu+tcp:///) which is "good enough" since all virtualisation hosts are on a separate and "secure" management subnet and VLAN.

But I just tried the qemu+tls:/// connections again just now, to six different virtualisation hosts and I *can't* reproduce this problem any more.

The hosts are all running Ubuntu 12.04.5, some with the Trusty HWE kernel (e.g. 3.13.0-40-generic), some with the original Precise kernel (e.g. 3.2.0-74-generic). Libvirt is installed in version 0.9.8-2ubuntu17.20. The Libvirt client in all cases is also a Ubuntu 12.04.5 machine, also running Libvirt 0.9.8-2ubuntu17.20.

We currently also leverage our Puppet CA and use the issued certificates not only for Puppet but also for Libvirt and other services. I don't think this makes a difference but two years ago when I ran into this problem we were using keys and certificates issued by our own internal CA.

So to me this looks resolved but since I have no idea what caused the problem originally and what exactly has changed in Libvirt since then in that regard I can only really say "WORKSFORME".