Description of problem:
On fedora 11, when I run virt-manager, it asks me for the root password.
On rawhide when I do the same thing, this happens:
Unable to open connection to hypervisor URI 'qemu:///system':
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 456, in _try_open
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Tells me it can't connect to libvirtd
Asks for authentication, then connects
I didn't install virtualization initially on this machine, but
later did a yum groupinstall to get it, don't know if that affected
permissions on something or what.
Are you using ssh -X or su to change user? I have the same problem if I 'su - <user>' as another regular user. It's probably some PolicyKit quirk.
Nope, I just login to gnome session as standard user and run virt-manager
from the system tools menu, and instead of getting an authentication
prompt, I get the error.
If I open a terminal and run:
sudo su -l
that copy of virt-manager works fine (and doesn't ask for any credentials).
Hmm, is this still happening?
How about if, from a non-root terminal in the desktop session, you do:
$> virsh -c qemu:///system list --all
you should get a dialog asking for the root password and the command should succeed.
With virt-manager, once you've entered the root password, libvirtd runs the pkcheck program to check if the virt-manager pid is authorized
Do you see anything in /var/log/messages when the virt-manager error occurs?
I made a brand new user just to make sure no junk was laying around in ~/
to cause this problem, and both the virsh command above and running
virt-manager from the menus works fine, I get the login prompt, so it has
either been fixed, or something is screwed up for my original user.
Back as my original user, it still screws up, and I see this appear
Oct 2 09:48:11 zooty libvirtd: 09:48:11.300: error : remoteDispatchAuthPolkit:3168 : Policy kit denied action org.libvirt.unix.manage from pid 4136, uid 500, result: 512#012
No sure what I've done to this user, but I'll be re-installing from scratch
with the beta comes out, so it will probably get fixed then.
Okay, I assume this happens with virsh too? Moving to libvirt, in that case
We should figure out what's going on here before you delete that account
davidz, danpb: any ideas for debugging this?
Yep, virsh also does not work.
Just a random wild theory: Are there things like policykit hooks that get run
when setting up a new account? I did not have any of the Virtualization
packages install at the time the initial account was created. I did
a "yum groupinstall" much later to get the virt stuff for testing.
I bet it has something to do with the startup app PolicyKit Authentication Agent not existing in the list of startup apps for the user where this isn't working.
Yeah previously this auth agent would start on demand, since the client app was responsible to launching it. With new policykit it is expected to be running all the time, since the policykit backend talks directly to it, bypassing the client app. So if its not in your startup apps that'd be the problem.
Tom, you said that when you start virt-manager a dialog pops up asking for the root password? Is that still the case? I thought it was the PolicyKit Authentication Agent that did that?
I get the dialog on fedora 11, not fedora 12 (at least not fedora 12
when logged in as the user missing the policykit daemon).
P.S. I can't imagine why it is a good idea to require yet another stoopid
gnome daemon to be running all the time just so it will be able to ask
a question maybe once a day (pretty soon you are gonna have to change
linux to use 64 integers for PIDs just so gnome can run :-).
(In reply to comment #11)
> I get the dialog on fedora 11, not fedora 12
Cool, the missing agent explains it then; moving to policy kit
davidz: does the agent get enabled for existing users if you update from F-11 to F-12?
polkit-gnome provides/obosoletes PolicyKit-gnome and
polkit-gnome installs /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop
so: yes, existing users should get the agent enabled.
Cool, let's assume this is some random screwup then. Closing as WORKSFORME