View Full Version : [PC-BSD] Virt-manager: Unable to open a connection to the libvirtd management daemon
pc-bsd
March 15th, 2012, 11:36
Good day, FreeBSD experts!
I am new in PC-BSD 9, so asking your help/advice.
Problem with virt-manager - program cannot start: writes this error:
Unable to open a connection to the libvirtd management daemon
Libvirt URI is: qemu:///system
Verify that: - The 'libvirtd' daemon has been started
I have tried to install from AppCafe, and from console-port: the same error:
Please help:
What config file should I change? Or how to start this libvirtd daemon? In Fedora - all works perfectly, what is with FreeBSD?
Google say- no answer yet in Internet :):P
SirDice
March 15th, 2012, 12:12
I am new in pc-bsd 9, so ask your help/advise
Topics about PC-BSD | FreeNAS | DesktopBSD | m0N0WALL | pfSense | Debian GNU/kFreeBSD
DutchDaemon
March 15th, 2012, 12:14
For the record: FreeBSD and PC-BSD have major differences, and this is not a PC-BSD forum, so make sure you read the disclaimer:
Topics about PC-BSD | FreeNAS | DesktopBSD | m0N0WALL | pfSense | Debian GNU/kFreeBSD (http://forums.freebsd.org/showthread.php?t=7290)
Also, use the proper post formatting, read your signup email.
DutchDaemon
March 15th, 2012, 12:14
Thank you, colleague Dice!
pc-bsd
March 15th, 2012, 12:20
Hmmm, Sir!
Ok, ok. But if I install KDE desktop to FreeBSD can I ask questions here? :) Funny story - holywar? :)
SirDice
March 15th, 2012, 12:23
Ok, ok. But if I install KDE desktop to FreeBSD can i ask questions here? :)
As long as it's really FreeBSD, yes.
Funny story - holywar? :)
No holy war. There's a lot of love between the two projects. The point is that PC-BSD works quite differently. Solutions that work on FreeBSD may not work on PC-BSD and vice versa.
pc-bsd
March 15th, 2012, 16:58
Dear, experts!
Today I tried to install Virt-manager in FreeBSD 9 x64 (install OS, KDE + XORG).
Hmmm - of course the same error like in bp-bsd:
Unable to open a connection to the libvirtd management daemon
Libvirt URI is: qemu:///system
Verify that: - The 'libvirtd' daemon has been started
Now I speak about FreeBSD! Not about pc-bsd. But computer says the same :)
So, how to manage this error?
phoenix
March 15th, 2012, 17:03
Have you started libvirtd(8) (http://www.freebsd.org/cgi/man.cgi?query=libvirtd&apropos=0&sektion=8&manpath=FreeBSD+9.0-RELEASE+and+Ports&arch=default&format=html)?
pc-bsd
March 15th, 2012, 19:15
Yes, I tried this:
1. Start libvirtd daemon with command in console libvirtd -d
2. Seems here is not-ready config files - because named /usr/local/etc/libvirt/libvirt.conf.sample I have renamed it to libvirt.conf
3. Here is still some error when check libvirt in concole:
localhost# libvirtd -d
libvirtd: error: Unable to obtain pidfile. Check /var/log/messages or run without --daemon for more info.
localhost# libvirtd
2012-03-15 22:03:27.332: 67142656: info : libvirt version: 0.9.7
2012-03-15 22:03:27.332: 67142656: error : virPidFileAcquirePath:345 : Failed to acquire pid file '/usr/local/var/run/libvirtd.pid': Resource temporarily unavailable
(This file /usr/local/var/run/libvirtd.pid exists).
What should I do? Probably something with configuration files I think.
serverhamster
March 15th, 2012, 20:15
What does it say when you try:
> virt-manager --debug --connect=qemu:///system
Also, do you want to connect to a local libvirt daemon to manage qemu, or remote? (remote would be qemu+ssh or something else.)
I'm actually asking because I have similar issues (http://forums.pcbsd.org/showthread.php?t=16430) getting virt-manager to connect on, eh, PC-BSD. I'm curious about the output on FreeBSD, but my FreeBSD systems are command-line only. It would at least be interesting to know whether it is working on FreeBSD or not. If not, both projects could benefit from a fix.
DutchDaemon
March 15th, 2012, 20:27
pc-bsd, read your signup email about some of the formatting rules (http://forums.freebsd.org/showthread.php?t=11799) we have here.
pc-bsd
March 15th, 2012, 20:44
I tried command:
localhost# virt-manager --debug --connect=qemu:///system
Here was long answer:
2012-03-15 23:40:48,273 (cli:71): virt-manager startup
2012-03-15 23:40:48,274 (virt-manager:292): Launched as: /usr/local/share/virt-manager/virt-manager.py --debug --connect=qemu:///system
2012-03-15 23:40:48,274 (virt-manager:293): GTK version: (2, 24, 6)
2012-03-15 23:40:48,274 (virt-manager:294): virtManager import: <module 'virtManager' from '/usr/local/share/virt-manager/virtManager/__init__.pyc'>
2012-03-15 23:40:48,372 (keyring:30): gnomekeyring bindings not installed, no keyring support
2012-03-15 23:40:48,497 (engine:555): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe.
2012-03-15 23:40:48,503 (engine:346): About to connect to uris ['qemu:///system']
2012-03-15 23:40:48,558 (engine:471): window counter incremented to 1
2012-03-15 23:40:48,571 (connection:954): Scheduling background open thread for qemu:///system
2012-03-15 23:40:48,573 (connection:1140): Background 'open connection' thread is running
2012-03-15 23:40:48,583 (connection:1168): Background open thread complete, scheduling notify
2012-03-15 23:40:48,615 (connection:1173): Notifying open result
2012-03-15 23:40:48,615 (error:80): dialog message: Unable to open a connection to the libvirt management daemon.
Libvirt URI is: qemu:///system
Verify that:
- The 'libvirtd' daemon has been started
: Unable to open a connection to the libvirt management daemon.
Libvirt URI is: qemu:///system
Verify that:
- The 'libvirtd' daemon has been started
no connection driver available for No connection for URI qemu:///system
Traceback (most recent call last):
File "/usr/local/share/virt-manager/virtManager/connection.py", line 1146, in _open_thread
self.vmm = self._try_open()
File "/usr/local/share/virt-manager/virtManager/connection.py", line 1130, in _try_open
flags)
File "/usr/local/lib/python2.7/site-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: no connection driver available for No connection for URI qemu:///system
2012-03-15 23:40:54,531 (engine:475): window counter decremented to 0
2012-03-15 23:40:54,542 (engine:550): Exiting app normally.
phoenix
March 15th, 2012, 21:10
No sense starting (or even using) virt-manager until you have libvirtd running successfully. Just forget virt-manager even exists until then. Concentrate on libvirtd for now.
What user are you trying to run libvirtd as? Or what user is it configured to run as?
Can that user access every part of the path /usr/local/var/run/libvirtd.pid (as in, can it access /usr /usr/local /usr/local/var /usr/local/var/run /usr/local/var/run/libvirtd.pid)? Are you sure it should even be trying to access that file, and not /var/run/libvirtd.pid (which is the normal directory for PID files)?
What's in the config file for libvirtd?
phoenix
March 15th, 2012, 21:37
Edit /usr/local/etc/libvirt/libvirtd.conf and change the Socket Directory to /var/run/libvirt. As root, create the /var/run/libvirt directory.
Next, edit the config file and uncomment the line near the top for listen_tls.
Then start libvirtd. Works just fine here:
[root@betadrive local/etc/libvirt]# libvirtd --daemon
[root@betadrive local/etc/libvirt]# pgrep -lf libvirt
10907 libvirtd --daemon
[root@betadrive local/etc/libvirt]# uname -a
FreeBSD betadrive.sd73.bc.ca 9.0-STABLE FreeBSD 9.0-STABLE #0 r231298: Thu Feb 9 13:50:34 PST 2012 root@betadrive.sd73.bc.ca:/usr/obj/usr/src/sys/ZFSHOST90
pc-bsd
March 16th, 2012, 09:08
Good day!
Phoenix, can you please send a working libvirtd.conf file? I think here is the problem!
I should say from the installing there were 2 files in directory: /usr/local/etc/libvirt/ but with a .sample extension, libvirtd.conf.sample and libvirt.conf.sample.
Why freebsd FreeBSD core engineers try to make programs start so pervert..
So, I rename libvirtd.conf.sample ==> libvirtd.conf.
But it still doesn't work.
Here is my file:
# Master libvirt daemon configuration file
#
# For further information consult http://libvirt.org/format.html
################################################## ###############
#
# Network connectivity controls
#
# Flag listening for secure TLS connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# It is necessary to setup a CA and issue server certificates before
# using this capability.
#
# This is enabled by default, uncomment this to disable it
listen_tls = 0
# Listen for unencrypted TCP connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# Using the TCP socket requires SASL authentication by default. Only
# SASL mechanisms which support data encryption are allowed. This is
# DIGEST_MD5 and GSSAPI (Kerberos5)
#
# This is disabled by default, uncomment this to enable it.
#listen_tcp = 1
# Override the port for accepting secure TLS connections
# This can be a port number, or service name
#
#tls_port = "16514"
# Override the port for accepting insecure TCP connections
# This can be a port number, or service name
#
#tcp_port = "16509"
# Override the default configuration which binds to all network
# interfaces. This can be a numeric IPv4/6 address, or hostname
#
# listen_addr = "192.168.0.1"
# Flag toggling mDNS advertizement of the libvirt service.
#
# Alternatively can disable for all services on a host by
# stopping the Avahi daemon
#
# This is enabled by default, uncomment this to disable it
#mdns_adv = 0
# Override the default mDNS advertizement name. This must be
# unique on the immediate broadcast network.
#
# The default is "Virtualization Host HOSTNAME", where HOSTNAME
# is subsituted for the short hostname of the machine (without domain)
#
#mdns_name = "Virtualization Host Joe Demo"
################################################## ###############
#
# UNIX socket access controls
#
# Set the UNIX domain socket group ownership. This can be used to
# allow a 'trusted' set of users access to management capabilities
# without becoming root.
#
# This is restricted to 'root' by default.
#unix_sock_group = "libvirt"
# Set the UNIX socket permissions for the R/O socket. This is used
# for monitoring VM status only
#
# Default allows any user. If setting group ownership may want to
# restrict this to:
unix_sock_ro_perms = "0777"
# Set the UNIX socket permissions for the R/W socket. This is used
# for full management of VMs
#
# Default allows only root. If PolicyKit is enabled on the socket,
# the default will change to allow everyone (eg, 0777)
#
# If not using PolicyKit and setting group ownership for access
# control then you may want to relax this to:
unix_sock_rw_perms = "0777"
################################################## ###############
#
# Authentication.
#
# - none: do not perform auth checks. If you can connect to the
# socket you are allowed. This is suitable if there are
# restrictions on connecting to the socket (eg, UNIX
# socket permissions), or if there is a lower layer in
# the network providing auth (eg, TLS/x509 certificates)
#
# - sasl: use SASL infrastructure. The actual auth scheme is then
# controlled from /etc/sasl2/libvirt.conf. For the TCP
# socket only GSSAPI & DIGEST-MD5 mechanisms will be used.
# For non-TCP or TLS sockets, any scheme is allowed.
#
# - polkit: use PolicyKit to authenticate. This is only suitable
# for use on the UNIX sockets. The default policy will
# require a user to supply their own password to gain
# full read/write access (aka sudo like), while anyone
# is allowed read/only access.
#
# Set an authentication scheme for UNIX read-only sockets
# By default socket permissions allow anyone to connect
#
# To restrict monitoring of domains you may wish to enable
# an authentication mechanism here
auth_unix_ro = "none"
# Set an authentication scheme for UNIX read-write sockets
# By default socket permissions only allow root. If PolicyKit
# support was compiled into libvirt, the default will be to
# use 'polkit' auth.
#
# If the unix_sock_rw_perms are changed you may wish to enable
# an authentication mechanism here
auth_unix_rw = "none"
# Change the authentication scheme for TCP sockets.
#
# If you don't enable SASL, then all TCP traffic is cleartext.
# Don't do this outside of a dev/test scenario. For real world
# use, always enable SASL and use the GSSAPI or DIGEST-MD5
# mechanism in /etc/sasl2/libvirt.conf
#auth_tcp = "sasl"
phoenix
March 16th, 2012, 17:16
See attached file for devel/libvirt 0.9.6. Only 2 lines were changed:
listen_tls = 0 was uncommented
unix_sock_dir = "/var/run/libvirt" was uncommented
Everything else is the default installed by the port.
[root@betadrive local/etc/libvirt]# libvirtd -d
[root@betadrive local/etc/libvirt]# pgrep -lf libvirt
33565 libvirtd -d
[root@betadrive local/etc/libvirt]# ls -l /var/run/libvirt/
total 0
srwx------ 1 root wheel 0 Mar 16 09:11 libvirt-sock
srwxrwxrwx 1 root wheel 0 Mar 16 09:11 libvirt-sock-ro
pc-bsd
March 17th, 2012, 15:22
Hello! Still not working. Now it shows an error about PID file not available, but actually the file exists and I set all possible access permissions to this file.
What can be the problem?
localhost# libvirtd -d
libvirtd: error: Unable to obtain pidfile. Check /var/log/messages or run without --daemon for more info.
localhost# libvirtd
2012-03-17 18:19:32.771: 67142656: info : libvirt version: 0.9.7
2012-03-17 18:19:32.771: 67142656: error : virPidFileAcquirePath:345 : Failed to acquire pid file '/usr/local/var/run/libvirtd.pid': Resource temporarily unavailable
localhost#
phoenix
March 19th, 2012, 18:13
Did you set the PID directory in the config file? It's showing a non-standard location (/usr/local/var/run/libvirtd.pid) that does not show up in my install of 0.9.6.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.
0