Description Philipp Hahn 2014-06-06 08:40:16 CEST

+++ This bug was initially created as a clone of Bug #33966 +++
libvirt-check.sh uses URI=xen+unix:///, which uses the local UNIX domain socket /var/run/libvirt/libvirt-sock[-ro].
In three test instances the UNIX socket still works, but not the TCP socket at port 16514:

# telnet lynx1.phahn.dev 16514
Trying 10.200.17.241...
telnet: connect to address 10.200.17.241: Connection refused

# tcpdump -i peth0 tcp port 16514
08:26:06.508855 IP xen12.phahn.dev.53876 > lynx1.phahn.dev.16514: Flags [S], seq 1350119682, win 14600, options [mss 1460,sackOK,TS val 43213358 ecr 0,nop,wscale 7], length 0
08:26:06.508912 IP lynx1.phahn.dev.16514 > xen12.phahn.dev.53876: Flags [R.], seq 0, ack 1350119683, win 0, length 0


Simply using xen://localhost/ does not work, because that would require the libvirt-PKI to be setup for client access on all nodes too. Currently we only setup the server part on nodes and the client part on the UVMMd host(s):

# virsh -c xen://lynx1.phahn.dev/
error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': Datei oder Verzeichnis nicht gefunden
error: failed to connect to the hypervisor


Getting a gdb BT failed because libvirt-check.sh kill-9-ed the process while the debugger was attached and had the process stopped.
After the automatic restart "virsh -c xen://lynx1.phahn.dev/" was working again.