Bug 787377 - virt-manager cannot connect to hypervisor - authentication failed
Summary: virt-manager cannot connect to hypervisor - authentication failed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 16
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-04 16:19 UTC by Vladimir Pakhomov
Modified: 2012-12-15 19:26 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-06 19:04:08 UTC
Type: ---


Attachments (Terms of Use)
See comment #9 (4.42 KB, application/zip)
2012-02-05 21:10 UTC, Vladimir Pakhomov
no flags Details

Description Vladimir Pakhomov 2012-02-04 16:19:50 UTC
Description of problem:

When I try to start virt-manager as a regular user or root an "Authentication required" dialog appeared and after entering credintials appeared the following error:

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
    flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed: authentication failed

I also get an authentication request when I try to use "sudo virsh list" command.

Version-Release number of selected component (if applicable):
libvirt-0.9.6-4.fc16.x86_64
polkit-0.102-3.fc16.x86_64
polkit-0.102-3.fc16.i686
virt-manager-0.9.0-7.fc16.noarch

How reproducible:
Always for me


Steps to Reproduce:
1.$virt-manager or #virt-manager
2.
3.
  
Actual results:
virt-manager cannot connect to local hypervisor

Expected results:
virt-manager can connect to local hypervisor

Additional info:
System upgraded using preupgrade command
# cat /etc/redhat-release 
Fedora release 16 (Verne)
#systemctl status libvirtd.service
libvirtd.service - LSB: daemon for libvirt virtualization API
	  Loaded: loaded (/etc/rc.d/init.d/libvirtd)
	  Active: active (running) since Sat, 04 Feb 2012 19:52:16 +0400; 18min ago
	 Process: 3595 ExecStop=/etc/rc.d/init.d/libvirtd stop (code=exited, status=0/SUCCESS)
	 Process: 3601 ExecStart=/etc/rc.d/init.d/libvirtd start (code=exited, status=0/SUCCESS)
	Main PID: 3607 (libvirtd)
	  CGroup: name=systemd:/system/libvirtd.service
		  ├ 2013 /usr/sbin/dnsmasq --strict-order --bind-interfaces...
		  ├ 2043 /usr/sbin/dnsmasq --strict-order --bind-interfaces...
		  └ 3607 libvirtd --daemon --listen

# ps auxww | grep polkit | grep -v grep
root      1759  0.0  0.0 189452  4424 ?        Sl   19:31   0:00 /usr/libexec/polkit-1/polkitd --no-debug

I also checked Bug 579579 and tried suggested solutions - no luck.

Comment 1 Cole Robinson 2012-02-04 21:15:19 UTC
Thanks for the report. Please try the following:

as root:
killall polkitd
/usr/libexec/polkit-1/polkitd

as regular user in another terminal:
virsh --connect qemu:///system

Please report the output from both terminals

Comment 2 Vladimir Pakhomov 2012-02-05 04:26:19 UTC
Hello, here are outputs:

Terminal1:

# killall polkitd
# /usr/libexec/polkit-1/polkitd
Entering main event loop
Connected to the system bus
Registering null backend at priority -10
** (polkitd:2873): DEBUG: Added `/var/lib/polkit-1/localauthority/10-vendor.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/etc/polkit-1/localauthority/10-vendor.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/var/lib/polkit-1/localauthority/20-org.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/etc/polkit-1/localauthority/20-org.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/var/lib/polkit-1/localauthority/30-site.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/etc/polkit-1/localauthority/30-site.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/var/lib/polkit-1/localauthority/50-local.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/etc/polkit-1/localauthority/50-local.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/var/lib/polkit-1/localauthority/90-mandatory.d' as a local authorization store
** (polkitd:2873): DEBUG: Added `/etc/polkit-1/localauthority/90-mandatory.d' as a local authorization store
** (polkitd:2873): DEBUG: Monitoring `/var/lib/polkit-1/localauthority' for changes
** (polkitd:2873): DEBUG: Monitoring `/etc/polkit-1/localauthority' for changes
Using authority class PolkitBackendLocalAuthority
Acquired the name org.freedesktop.PolicyKit1
** (polkitd:2873): DEBUG: Added authentication agent for unix-session:/org/freedesktop/ConsoleKit/Session2 at name :1.65 [gnome-shell --sm-client-id 1090da93e89eab4dfa132361200741017200000022760000], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8


Terminal2:

$ virsh --connect qemu:///system
Please enter your authentication name: root
Please enter your password: 
error: authentication failed: authentication failed
error: failed to connect to the hypervisor
$ virsh --connect qemu:///system
Please enter your authentication name: vladimir
Please enter your password: 
error: authentication failed: authentication failed
error: failed to connect to the hypervisor

Comment 3 Cole Robinson 2012-02-05 15:06:28 UTC
Hmm, okay. What's the output of this command running from a bash prompt?

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

Comment 4 Vladimir Pakhomov 2012-02-05 18:17:13 UTC
When running first time as a regular user it asked for authorization and give the following as a result:

$ pkcheck --action-id org.libvirt.unix.manage --allow-user-interaction --process $BASHPID
polkit\56retains_authorization_after_challenge=true
polkit\56temporary_authorization_id=tmpauthz0

second time:

$ pkcheck --action-id org.libvirt.unix.manage --allow-user-interaction --process $BASHPID
polkit\56temporary_authorization_id=tmpauthz0


when running as root it does not give any output:

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

Comment 5 Cole Robinson 2012-02-05 18:35:12 UTC
Hmm, did any of those pkcheck commands ask for a password? What is the exit code of the command? (after it finishes, run the command 'echo $?')

Is selinux enabled? if so, does a setenforce 0 make any difference to the virsh --connect command?

Are you connecting to this machine over ssh -X or VNC or anything? Or physically sitting in front of the machine?

Comment 6 Cole Robinson 2012-02-05 18:58:11 UTC
Sorry, I see that you mentioned in comment #4 that the first run of pkcheck asked for a password. I'd still be interested in the exit code when you reproduce that.

Comment 7 Vladimir Pakhomov 2012-02-05 19:09:17 UTC
Only the first time when I opened terminal and run the pkcheck command provided
in your post as a regular user.
After that there were no password requests. The exit code of this command was 0
in all cases.

SELinux disabled completely:
# getenforce
Disabled

And I physically sitting in front of this machine.

Comment 8 Cole Robinson 2012-02-05 19:27:45 UTC
Hmm, alright. Let's try this.

as root:
service libvirtd stop
LIBVIRT_DEBUG=1 libvirtd > daemon_output 2>&1

as regular user:
LIBVIRT_DEBUG=1 virsh --connect qemu:///system 2> virsh_out

Enter password, verify it fails, and upload those 2 output files

Comment 9 Vladimir Pakhomov 2012-02-05 21:09:01 UTC
# service libvirtd stop
Stopping libvirtd (via systemctl):                         [  OK  ]
# LIBVIRT_DEBUG=1 libvirtd > daemon_output 2>&1


$ LIBVIRT_DEBUG=1 virsh --connect qemu:///system 2> virsh_out
Please enter your authentication name: root    
Please enter your password:
$ LIBVIRT_DEBUG=1 virsh --connect qemu:///system 2>> virsh_out
Please enter your authentication name: vladimir
Please enter your password:
$

Comment 10 Vladimir Pakhomov 2012-02-05 21:10:38 UTC
Created attachment 559506 [details]
See comment #9

See comment #9

Comment 11 Cole Robinson 2012-02-05 22:32:11 UTC
Hmm, for some reason your daemon output is really small, it should be huge.

But it looks like libvirt is trying to use sasl auth. Do you have kerberos or sasl setup? Have you made any changes to /etc/libvirt/libvirtd.conf? Maybe try removing that file and reinstalling libvirt with yum reinstall libvirt, see if it makes any difference.

Comment 12 Vladimir Pakhomov 2012-02-06 18:43:54 UTC
Oops....

It was really not virt-manager/libvirt/policykit issue but vdsm.
Some time ago I installed and removed vdsm- related packages but changes made by them remains in /etc/libvirt/libvirtd.conf, /etc/libvirt/qemu.conf and /ets/sysconfig/libvirtd files. After commenting out vdsm- related lines everything is OK. Thank you so much for help!

Comment 13 Cole Robinson 2012-02-06 19:04:08 UTC
No worries, now I know one more way libvirt authentication can break :) Closing as NOTABUG

Comment 14 Lukas Zapletal 2012-12-15 19:26:43 UTC
I saw the same issue when I try to connect to my libvirt with kerberos configured on my laptop while VPN is down.


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