Bug 579579 - virt-manager: provide better feedback if we can determine why policykit failed
Summary: virt-manager: provide better feedback if we can determine why policykit failed
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 642752 869747 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-05 22:12 UTC by Aioanei Rares
Modified: 2012-10-24 19:09 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-27 23:52:25 UTC
Type: ---


Attachments (Terms of Use)

Description Aioanei Rares 2010-04-05 22:12:54 UTC
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:

Comment 1 Cole Robinson 2010-04-13 00:04:48 UTC
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?

Comment 2 Aioanei Rares 2010-04-13 11:53:38 UTC
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

Comment 3 Cole Robinson 2010-05-10 18:07:33 UTC
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?

Comment 4 Aioanei Rares 2010-05-10 18:50:10 UTC
Sorry, don't have F12 installed anymore, only F13.

Comment 5 Cole Robinson 2010-05-10 19:35:31 UTC
Closing as WORKSFORME

Comment 6 Tethys 2010-07-10 23:16:38 UTC
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.

Comment 7 Jeff Bastian 2010-08-18 21:07:48 UTC
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>

Comment 8 Bug Zapper 2010-11-03 17:47:59 UTC
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

Comment 9 Tethys 2010-11-03 21:51:13 UTC
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.

Comment 10 Craig 2010-11-12 10:46:54 UTC
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)

Comment 11 Craig 2010-11-17 15:46:20 UTC
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.

Comment 12 Dan Poler 2010-11-27 02:15:13 UTC
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

Comment 13 Tethys 2010-11-27 12:51:54 UTC
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

Comment 14 Lonni J Friedman 2010-12-27 23:42:27 UTC
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
#############

Comment 15 Paul F. Johnson 2011-01-09 18:07:18 UTC
Also happening in rawhide

Comment 16 Hongqing Yang 2011-01-26 08:13:08 UTC
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)

Comment 17 Cole Robinson 2011-03-23 21:45:51 UTC
*** Bug 642752 has been marked as a duplicate of this bug. ***

Comment 18 Cole Robinson 2011-03-23 22:22:39 UTC
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?

Comment 19 Ted W. 2011-04-11 18:28:58 UTC
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

Comment 20 Ted W. 2011-04-11 19:15:37 UTC
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.

Comment 21 Cole Robinson 2011-04-11 21:15:29 UTC
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)

Comment 22 Bug Zapper 2011-06-02 15:40:46 UTC
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

Comment 23 Cole Robinson 2011-06-10 16:58:29 UTC
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.

Comment 24 Paul Egan 2011-09-06 03:20:49 UTC
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

Comment 25 Hitoshi Fukajima 2012-01-03 02:12:29 UTC
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.

Comment 26 Cole Robinson 2012-01-17 22:44:59 UTC
Reassigning to rawhide and retitling, we need to provide better feedback to users in this case.

Comment 27 Cole Robinson 2012-01-27 23:52:25 UTC
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.

Comment 28 Dave Allan 2012-10-24 19:09:45 UTC
*** Bug 869747 has been marked as a duplicate of this bug. ***


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