Bug 579579

Can you provide:

- Output of virt-manager --debug when run as a regular user
- rpm -qa | grep polkit

Also, are you running virt-manager on a local machine, or over SSH or VNC or something like that?

1. [arares@localhost: ~]$ sudo /etc/init.d/libvirtd start
[sudo] password for arares: 
Starting libvirtd daemon: 
[arares@localhost: ~]$ virt-manager --debug
2010-04-13 14:52:18,394 (virt-manager:150): Application startup
2010-04-13 14:52:18,685 (engine:129): About to connect to uris ['qemu:///system', 'xen:///']
2010-04-13 14:52:18,759 (engine:414): window counter incremented to 1
2010-04-13 14:52:18,823 (connection:749): Scheduling background open thread for qemu:///system
2010-04-13 14:52:18,834 (connection:882): Background thread is running
2010-04-13 14:52:18,867 (connection:917): Unable to open connection to hypervisor URI 'qemu:///system':
authentication failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 872, in _try_open
    None], flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed

2010-04-13 14:52:18,867 (connection:922): Background open thread complete, scheduling notify
2010-04-13 14:52:18,910 (connection:927): Notifying open result
2010-04-13 14:52:18,911 (error:79): Uncaught Error: 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 connection to hypervisor URI 'qemu:///system':
authentication failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 872, in _try_open
    None], flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed

2010-04-13 14:52:33,815 (engine:427): Exiting app normally.
[arares@localhost: ~]$ 

2. [arares@localhost: ~]$ rpm -qa | grep polkit
polkit-desktop-policy-0.95-0.git20090913.3.fc12.noarch
polkit-0.95-0.git20090913.3.fc12.x86_64
polkit-gnome-0.95-0.git20090913.6.fc12.x86_64
polkit-qt-0.95.1-3.fc12.x86_64
[arares@localhost: ~]$ 

3. local machine

If you can still reproduce this, what's the output of:

ps axwww | grep polkit
/usr/libexec/polkit-gnome-authentication-agent-1

Do any other polkit interactions launch a dialog, like trying to change the system time as a regular user?

Sorry, don't have F12 installed anymore, only F13.

Closing as WORKSFORME

Please reopen this bug. I get exactly the same problem with a fresh F13
install (on x86_64, if it matters).

dresden:~% virt-manager --debug
2010-07-10 23:10:27,756 (virt-manager:161): Application startup
2010-07-10 23:10:28,087 (engine:338): About to connect to uris ['qemu:///system']
2010-07-10 23:10:28,152 (engine:629): window counter incremented to 1
2010-07-10 23:10:28,189 (connection:836): Scheduling background open thread for qemu:///system
2010-07-10 23:10:28,190 (connection:981): Background thread is running
2010-07-10 23:10:28,235 (connection:1019): Background open thread complete, scheduling notify
2010-07-10 23:10:28,237 (connection:1024): Notifying open result
2010-07-10 23:10:28,239 (error:86): Uncaught Error: 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 connection to hypervisor URI 'qemu:///system':
authentication failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 971, in _try_open
    None], flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed

2010-07-10 23:10:33,099 (engine:642): Exiting app normally.
dresden:~% 
dresden:~% rpm -qa | grep polkit
polkit-0.96-1.fc13.x86_64
dresden:~% 
dresden:~% ps auxww | egrep '(polkit|libvirt)'
nobody    2858  0.0  0.0  12784   700 ?        S    22:54   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file=  --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253
root      3054  0.0  0.1  49424  3628 ?        S    22:54   0:00 /usr/libexec/polkit-1/polkitd
root      3372  0.4  1.3 623548 28072 ?        Sl   23:06   0:01 libvirtd --daemon
tet       3540  0.0  0.0 100916   840 pts/2    S+   23:12   0:00 egrep (polkit|libvirt)

Hardware details:
http://www.smolts.org/client/show/pub_7a33aaea-9e1f-4b6a-b5aa-a6d0208b46d6

It works fine if I run it as root, although I'm naturally wary of
doing so. If you need any extra information, please let me know.

I was having this same problem when running in a VNC session.  I changed the libvirt security policy's allow_any and allow_inactive settings from 'no' to 'auth_admin' (see below) and now it asks for the root password when I start virt-manager.


--- /usr/share/polkit-1/actions/org.libvirt.unix.policy.ORIG 2010-08-11
04:15:04.000000000 -0500
+++ /usr/share/polkit-1/actions/org.libvirt.unix.policy 2010-08-18
15:55:23.529641403 -0500
@@ -34,8 +34,8 @@
       <defaults>
         <!-- Only a program in the active host session can use libvirt in
              read-write mode for management, and we require user password -->
-        <allow_any>no</allow_any>
-        <allow_inactive>no</allow_inactive>
+        <allow_any>auth_admin</allow_any>
+        <allow_inactive>auth_admin</allow_inactive>
         <allow_active>auth_admin_keep</allow_active>
       </defaults>
     </action>

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

See comment #6. This is still a problem on F13. I'd update the bug,
but I don't have permission to change the version field.

Still in 14 as well.

bash-4.1$ virt-manager --debug
2010-11-12 10:43:50,728 (virt-manager:161): Application startup
2010-11-12 10:43:50,729 (virt-manager:300): Launched as: /usr/share/virt-manager/virt-manager.py --debug
/usr/lib/python2.7/site-packages/dbus/types.py:6: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  from _dbus_bindings import ObjectPath, ByteArray, Signature, Byte,\
2010-11-12 10:43:50,868 (engine:348): About to connect to uris ['qemu+ssh://cwhildin@gba-cwhildin-fed/system', 'qemu:///system']
2010-11-12 10:43:50,904 (engine:643): window counter incremented to 1
2010-11-12 10:43:50,911 (connection:848): Scheduling background open thread for qemu:///system
2010-11-12 10:43:50,912 (connection:993): Background thread is running
2010-11-12 10:43:50,962 (connection:1021): Background open thread complete, scheduling notify
2010-11-12 10:43:50,963 (connection:1026): Notifying open result
2010-11-12 10:43:50,964 (error:86): Uncaught 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

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 983, in _try_open
    None], flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 111, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed

bash-4.1$ rpm -qa | grep polkit
polkit-desktop-policy-0.98-4.fc14.noarch
polkit-0.98-4.fc14.x86_64
polkit-gnome-0.97-4.fc14.x86_64

bash-4.1$ ps auxww | egrep '(polkit|libvirt)'
root      1418  0.0  0.0 241444  5456 ?        Sl   Nov11   0:00 /usr/libexec/polkit-1/polkitd
nobody    1965  0.0  0.0  13020   724 ?        S    Nov11   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file=  --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253
gdm       2050  0.0  0.1 315368  7868 ?        Sl   Nov11   0:00 /usr/libexec/polkit-gnome-authentication-agent-1
root      4465  0.0  0.1 537956  6704 ?        Sl   Nov11   0:00 libvirtd --daemon
cwhildin 10314  0.0  0.0 101152   856 pts/1    S+   10:45   0:00 egrep (polkit|libvirt)

This is now correctly asking me for root credentials on startup though I do have the modification to /usr/share/polkit-1/actions/org.libvirt.unix.policy

     <defaults>
        <!-- Only a program in the active host session can use libvirt in
             read-write mode for management, and we require user password -->
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
      </defaults>

Polkit hasn't updated but I have applied all updates released to my install.

This bug also exists in RHEL 6 -- and can be similarly resolved by the above.

virt-manager-0.8.4-8.el6.noarch
polkit-desktop-policy-0.96-2.el6.noarch

Even with the changes to org.libvirt.unix.policy, I still get the same
error, and don't get asked for root credentials.

polkit-0.96-1.fc13.x86_64
virt-manager-0.8.5-1.fc13.noarch

I'm also seeing this bug in F14-x86_64 when running virt-manager over ssh as a non-root user.  The changes to /usr/share/polkit-1/actions/org.libvirt.unix.policy have no impact, I always get the same 



polkit-0.98-4.fc14.x86_64
virt-manager-0.8.5-1.fc14.noarch

##############
$ virt-manager --debug
2010-12-27 15:41:45,903 (virt-manager:161): Application startup
2010-12-27 15:41:45,903 (virt-manager:300): Launched as: /usr/share/virt-manager/virt-manager.py --debug
/usr/lib/python2.7/site-packages/dbus/types.py:6: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  from _dbus_bindings import ObjectPath, ByteArray, Signature, Byte,\
2010-12-27 15:41:46,065 (engine:348): About to connect to uris ['qemu:///system']
2010-12-27 15:41:46,098 (engine:643): window counter incremented to 1
2010-12-27 15:41:46,113 (connection:848): Scheduling background open thread for qemu:///system
2010-12-27 15:41:46,114 (connection:993): Background thread is running
2010-12-27 15:41:46,148 (connection:1021): Background open thread complete, scheduling notify
2010-12-27 15:41:46,148 (connection:1026): Notifying open result
2010-12-27 15:41:46,149 (error:86): Uncaught 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

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 983, in _try_open
    None], flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 111, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed
#############

Also happening in rawhide

I have the same problem
if I start with regular user, it gives message,prompts password and  starts up
/usr/lib/python2.7/site-packages/dbus/types.py:6: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  from _dbus_bindings import ObjectPath, ByteArray, Signature, Byte,\

if I use sudo , it also gives the same message.

if I use root, it does not start up and gives message

/usr/lib/python2.7/site-packages/dbus/types.py:6: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  from _dbus_bindings import ObjectPath, ByteArray, Signature, Byte,\
**
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)
Aborted (core dumped)

*** Bug 642752 has been marked as a duplicate of this bug. ***

That last error in Comment #16 is another bug, I've filed it against gconf

https://bugzilla.redhat.com/show_bug.cgi?id=681390

For everyone else: the piece that authenticates us here is PolicyKit, PolicyKit
expects to be run in a regular desktop session, which it sounds like some of
you aren't doing. AFAIU it is expected that you will get the 'authentication
failed' error if you run virt-manager in the following ways:

1) using 'su' or 'sudo -sE' : these preserve the environment of your regular
user which confuses/angers desktop session services like PolicyKit. Try using
'su -'

2) over ssh -Y/-X as your regular user. AIUI, ssh -X doesn't set up a proper
desktop session, so policykit doesn't work there

3) over VNC as a regular user. policykit doesn't work there either

AIUI these are design decisions of PolicyKit/dbus so probably won't change
anytime soon. I'm going to try and find out if there is a way we can detect
these situations (possibly poking env variables?) and give the user a more
informative error message.

My question for everyone: is anyone seeing this problem outside of the above 3
scenarios? If so, are you doing anything else that may factor in?

I'm seeing this on my box running RHEL 6 (2.6.32-71.24.1.el6.x86_64) with the modifications mentioned above. This is the output running as root (su -)

2011-04-11 14:27:09,960 (virt-manager:161): Application startup
2011-04-11 14:27:10,180 (engine:348): About to connect to uris ['qemu:///system']
2011-04-11 14:27:10,227 (engine:643): window counter incremented to 1
2011-04-11 14:27:10,228 (connection:857): Scheduling background open thread for qemu:///system
2011-04-11 14:27:10,229 (connection:1002): Background thread is running
2011-04-11 14:27:10,232 (connection:1040): Background open thread complete, scheduling notify
2011-04-11 14:27:10,271 (connection:1045): Notifying open result
2011-04-11 14:27:10,272 (error:86): Uncaught Error: 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 connection to hypervisor URI 'qemu:///system':
unable to connect to '/var/run/libvirt/libvirt-sock', libvirtd may need to be started: No such file or directory
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 992, in _try_open
    None], flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: unable to connect to '/var/run/libvirt/libvirt-sock', libvirtd may need to be started: No such file or directory

It was working up until I rebooted today after applying some updates to the system a few days ago. I've listed below the packages I've updated/installed over the last month (anything from 2011-04-11 was my attempts to repair the issue).

qemu-kvm-tools-0.12.1.2-2.113.el6_0.8         Mon 11 Apr 2011 01:38:49 PM EDT
qemu-kvm-0.12.1.2-2.113.el6_0.8               Mon 11 Apr 2011 01:38:31 PM EDT
virt-manager-0.8.4-8.el6                      Mon 11 Apr 2011 01:28:33 PM EDT
python-virtinst-0.500.3-7.el6                 Mon 11 Apr 2011 01:28:24 PM EDT
libvirt-0.8.1-27.el6_0.5                      Mon 11 Apr 2011 01:28:21 PM EDT
virt-top-1.0.4-3.1.el6                        Mon 11 Apr 2011 01:28:18 PM EDT
virt-viewer-0.2.1-2.el6                       Mon 11 Apr 2011 01:28:15 PM EDT
libvirt-python-0.8.1-27.el6_0.5               Mon 11 Apr 2011 01:28:12 PM EDT
dhclient-4.1.1-12.P1.el6_0.4                  Mon 11 Apr 2011 10:23:50 AM EDT
kernel-devel-2.6.32-71.24.1.el6               Fri 08 Apr 2011 10:08:29 AM EDT
kernel-headers-2.6.32-71.24.1.el6             Fri 08 Apr 2011 10:08:22 AM EDT
kernel-2.6.32-71.24.1.el6                     Fri 08 Apr 2011 10:08:19 AM EDT
kernel-firmware-2.6.32-71.24.1.el6            Fri 08 Apr 2011 10:08:14 AM EDT
postfix-2.6.6-2.1.el6_0                       Fri 08 Apr 2011 08:25:53 AM EDT
glibc-2.12-1.7.el6_0.5                        Thu 07 Apr 2011 02:33:18 PM EDT
gpxe-roms-qemu-0.9.7-6.3.el6_0.1              Thu 07 Apr 2011 02:33:16 PM EDT
selinux-policy-targeted-3.7.19-54.el6_0.5     Thu 07 Apr 2011 02:32:43 PM EDT
glibc-devel-2.12-1.7.el6_0.5                  Thu 07 Apr 2011 02:32:42 PM EDT
nscd-2.12-1.7.el6_0.5                         Thu 07 Apr 2011 02:32:39 PM EDT
glibc-headers-2.12-1.7.el6_0.5                Thu 07 Apr 2011 02:32:37 PM EDT
selinux-policy-3.7.19-54.el6_0.5              Thu 07 Apr 2011 02:32:34 PM EDT
policycoreutils-2.0.83-19.8.el6_0             Thu 07 Apr 2011 02:32:31 PM EDT
glibc-common-2.12-1.7.el6_0.5                 Thu 07 Apr 2011 02:32:24 PM EDT
glibc-2.12-1.7.el6_0.5                        Thu 07 Apr 2011 02:32:10 PM EDT
tzdata-java-2011d-3.el6                       Mon 04 Apr 2011 08:55:51 AM EDT
tzdata-2011d-3.el6                            Mon 04 Apr 2011 08:55:45 AM EDT
logrotate-3.7.8-12.el6_0.1                    Mon 04 Apr 2011 08:55:42 AM EDT

Found a resolution for my issue after digging more. Confirm that the user and group lines (134 and 137) inside of /etc/libvirt/qemu.conf match your current user, even if running as root from su -, it will still fail unless these match a real user in the system.

Ted, that error you received usually means that libvirtd was not running, it shouldn't require any qemu.conf changes to work around (unless libvirt wasn't running because the config file was messed up, but the root problem from virt-manager's perspective is that libvirtd isn't running)

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Moving to F14 at least, still need to investigate further if we can provide better feedback to users when polkit isn't expected to work.

NB: In F15 /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop is no longer included with polkit-gnome.
http://pkgs.fedoraproject.org/gitweb/?p=polkit-gnome.git;a=commitdiff;h=0437824d399884b709b2a923d78cc5410d65be72

So if running a non-standard window manager you will need to manually start the auth agent.  I came across this issue when using i3 but fixed by adding this to my ~/.i3/config:

exec /usr/libexec/polkit-gnome-authentication-agent-1

I've fixed this issue like this.

1. Re-install some packages

  yum reinstall libvirt polkit policycore*

2. Log out and re-start libvirtd and virt-manager


I didn't reproduce this issue and try these steps again.
When upgrading Fedora from old version, polkit settings may have been broken.
I used yum directly to upgrade Fedora, it may occur these problems.

Reassigning to rawhide and retitling, we need to provide better feedback to users in this case.

Okay, I've added some patches to libvirt and virt-manager to try and give better error reporting here. virt-manager patch is:

http://git.fedorahosted.org/git?p=virt-manager.git;a=commit;h=2f10fc668c07d5e68f19c0cf2647af236e3c4393

I'm just closing this as UPSTREAM, but this stuff will definitely be in fedora 17. Backporting it would be a bit too intense.

If anyone out there is still having these issues on a recent version of fedora, please file a new bug and I'll try to help diagnose them.

*** Bug 869747 has been marked as a duplicate of this bug. ***