Bug 736953 - Unable to open a connection to the libvirt management daemon.
Summary: Unable to open a connection to the libvirt management daemon.
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-09 07:44 UTC by Jens Petersen
Modified: 2012-02-15 12:53 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-27 15:24:41 UTC

Attachments (Terms of Use)

Description Jens Petersen 2011-09-09 07:44:44 UTC
Description of problem:
I am not able to use virt-manager in F16.
It seems unable to connect to libvirtd.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start virt-manager in F16 after reboot
Actual results:
Dialog appears:

Unable to open a connection to the libvirt management daemon.

Libvirt URI is: qemu:///system

Verify that:
 - The 'libvirtd' daemon has been started

authentication failed: authentication failed

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1146, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1130, in _try_open
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed: authentication failed

Expected results:
no error

Comment 1 Cole Robinson 2011-09-26 15:50:04 UTC
Does running virt-manager as root work?
How about virsh --connect qemu:///system as root and non-root?

Comment 2 Nicolas Corrarello 2011-10-13 15:40:47 UTC
[sgtpepper@tardis ~]$ virsh --connect qemu:///system 
error: Cannot recv data: Connection reset by peer
error: failed to connect to the hypervisor

[sgtpepper@tardis ~]$ sudo service libvirtd status
libvirtd.service - LSB: daemon for libvirt virtualization API
	  Loaded: loaded (/etc/rc.d/init.d/libvirtd)
	  Active: active (running) since Thu, 13 Oct 2011 12:39:33 -0300; 35s ago
	 Process: 4089 ExecStop=/etc/rc.d/init.d/libvirtd stop (code=exited, status=0/SUCCESS)
	 Process: 4095 ExecStart=/etc/rc.d/init.d/libvirtd start (code=exited, status=0/SUCCESS)
	Main PID: 4101 (libvirtd)
	  CGroup: name=systemd:/system/libvirtd.service
		  ├ 1159 /usr/sbin/dnsmasq --strict-order --bind-interfaces...
		  ├ 1193 libvirtd --daemon
		  ├ 4101 libvirtd --daemon
		  └ 4150 libvirtd --daemon
Just in case, I checked /etc/hosts and added my hostname to localhost, but its still not working

Comment 3 Nicolas Corrarello 2011-10-13 15:41:33 UTC
By the way:

[sgtpepper@tardis ~]$ rpm -q libvirt
[sgtpepper@tardis ~]$ rpm -q virt-manager
[sgtpepper@tardis ~]$

Comment 4 Nicolas Corrarello 2011-10-13 15:54:42 UTC
I think I found out what's going on in my case. Virt-manager (or libvirt, I'm not sure) calls 
/usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py search-name installed qemu-system-x86
 to check if qemu is installed, if you're running yum (installing other packages this might create a timeout).

So basically don't start libvirt or virt-manager while running yum, until this is confirmed...

Comment 5 Jens Petersen 2011-11-17 01:15:49 UTC
Sorry this is long working for me now.

So I don't know what other people are seeing.

Comment 6 Jens Petersen 2011-11-17 01:18:03 UTC
Perhaps I add that I usually always reboot after installing
@virtualization to get dmsmasq, etc working: I could probably
avoid that with some commandline but rebooting is probably still faster. :)

Comment 7 Cole Robinson 2012-01-27 15:24:41 UTC
Hmm, doesn't sound like anyone is still actively having this problem, so closing WORKSFORME

Comment 8 Lars 2012-02-14 16:22:49 UTC
Hey guys!

Well, actually I still do have this problem in my fully patched FC16 -.-

And btw Cole: YES, it works as root, but not as my own user.

It works fine for my colleague on FC16, he started with a FC15 before upgrading. I started with 11 or 12... maybe that's the issue...

The Python traceback is the same for me (just in German), but has different line numbers (maybe a newer virt-manager version - 0.9.1, 2012-02-14 16:20:50.212+0000: 29817: info : libvirt version: 0.9.6, package: 4.fc16 (Fedora Project, 2011-12-19-20:27:37, x86-01.phx2.fedoraproject.org)).

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Authentifikation gescheitert: Authentifikation gescheitert

BTW: I installed everything necessary using 'yum install @virtualization', too.


Comment 9 Cole Robinson 2012-02-14 19:17:16 UTC
Lars, at a bash prompt, what's the output of this command:

pkcheck --action-id org.libvirt.unix.manage --allow-user-interaction --process $BASHPID

Comment 10 Lars 2012-02-15 12:37:21 UTC
Dear Cole,

thanks for your quick reply!

It shows nothing (not even an empty line) for root, but it shows "Not authorized." for my own user.

Okay, see, this is related to this policykit authentication agent stuff... Right? Found something related at #524732 and #750530... Maybe its because my agent cannot start because I use the Gnome 2 fallback desktop via NX client -.-

I will try getting the agent running... Or do you have an idea for me how to manage this?


Comment 11 Lars 2012-02-15 12:53:37 UTC
Cole, I figured out that this must be related to that fallback display stuff. Indeed, I can start virt-manager properly with my own user using default Gnome 3 desktop. He correctly asks me for my password and then can connect to libvirt management deamon and show me my running VMs...

It just does not work using Gnome 2 fallback using NX... Mmh, at least I have a workaround now and don't need to start it as root... but I still have to be at the server console directly, unfortunately -.-

Note You need to log in before you can comment on or make changes to this bug.