Description of problem: If I start virt-manager as regular user, it tells me that I should check if libvirtd is started and errors out (of course, since it doesn't have the necessary credentials). If I do a 'sudo virt-manager' from xterm, all works OK. Version-Release number of selected component (if applicable): virt-manager-0.8.2-1.fc12.noarch How reproducible: Everytime Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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. ***