0

I'm trying to set up libvirtd on my headless gentoo server. I'd like to have remote control via tls. I've followed libvirt remote access guide, but it don't work for me: client virt-manager shows following error:

unable to connect to libvirtd at 'xxx.xxx.info': Connection refused

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1055, in _try_open
    None], flags)
  File "/usr/lib/python2.6/site-packages/libvirt.py", line 107, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: unable to connect to libvirtd at 'xxx.xxx.info': Connection refused

Here is my current server libvirtd config (comments stripped):

listen_tls = 1 
tls_port = "16514"
auth_tls = "none"
tls_no_verify_address = 1

And it does not listens to port 16514: lsof -i tcp:16514 prints nothing.

I also have following in my log just after libvirtd start:

Mar 30 14:46:02 fs dnsmasq[27523]: started, version 2.52 cachesize 150
Mar 30 14:46:02 fs dnsmasq[27523]: compile time options: no-IPv6 GNU-getopt DBus I18N DHCP no-TFTP
Mar 30 14:46:02 fs dnsmasq-dhcp[27523]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
Mar 30 14:46:02 fs dnsmasq[27523]: reading /etc/resolv.conf
Mar 30 14:46:02 fs dnsmasq[27523]: using nameserver 192.168.1.3#53
Mar 30 14:46:02 fs dnsmasq[27523]: bad address at /etc/hosts line 2
Mar 30 14:46:02 fs dnsmasq[27523]: read /etc/hosts - 15 addresses
Mar 30 14:46:10 fs kernel: IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:18:82:ed:d1:df:08:00 SRC=172.28.36.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=62606 PROTO=2 
Mar 30 14:46:33 fs kernel: IN=virbr0 OUT= MAC=01:00:5e:00:00:01:26:a8:55:dc:5f:05:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 

"kernel: IN=virbr0" are dropped packets logged by -j LOG rule in my iptables config. However, I've tried with all iptables rules allowed - nothing changed.

Certs seems to be fine as well (maybe not?):

# ls -R /etc/pki/
/etc/pki/:
CA  libvirt

/etc/pki/CA:
ca.info  cacert.pem  cakey.pem

/etc/pki/libvirt:
private  servercert.pem

/etc/pki/libvirt/private:
server.info  servercert.pem  serverkey.pem

I'm on gentoo running

[ebuild   R   ] app-emulation/libvirt-0.8.8-r1  USE="json libvirtd lvm lxc network nls parted python qemu udev virt-network -avahi -caps -debug -iscsi -macvtap -nfs -numa -openvz -pcap -phyp -policykit -sasl (-selinux) -uml -virtualbox -xen" 0 kB

libvirtd is running:

# ps ax | grep [v]irt
30484 ?        Sl     0:00 /usr/sbin/libvirtd -d
30735 ?        S      0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file=  --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253 --dhcp-no-override

Anything else I should check. How do I debug this issue?

SOLVED:

I'd run libvirtd with --lsiten flag. It's possible to specify it in /etc/conf.d/libvirtd file. Also, I've found another error in my configuration: when adding connection in virt-manager, you must specify an hypervisor, so url would look like quemu+tsl://user@host/system, not just quemu+tsl://user@host/

rvs
  • 4,027
  • 1
  • 25
  • 30

1 Answers1

1

The starting point of your investigation should be here :

And it does not listens to port 16514: lsof -i tcp:16514 prints nothing

This is quite a low level issue : the daemon does not listen on the tcp port.

You should check for any log messages that could indicate an error, or launch the daemon manually in a terminal to see what it says...

petrus
  • 5,287
  • 25
  • 42
  • The problem that it does not prints any messages to logs or stdout even when launching from console with -v flag. – rvs Apr 02 '11 at 17:54
  • Oh... There is --listen switch, that should be specified for libvirt to listen network. You've not answered my question, but forced me to run libvirtd with --help. Thanks! – rvs Apr 02 '11 at 18:01
  • well, actually, sort of. Would you have run the daemon as executable if I didn't suggested it? ;) – petrus Apr 02 '11 at 20:02