[libvirt-users] Listing machines as non-root user
I have a problem with virsh. I'm using eucalyptus software on top of xen 4 (debian squeeze). The problem is that unix user "eucalyptus" cannot see vm machines when it executes "virsh list". My libvirt version is 0.8.8-3 from debian sid repository. The same problem occurs with older versions. What is more I have tried to change unix_sock_ro_perms to "2777". After libvirt restart it started to work. Even when I reverted this change it was still working. Unfortunately after server restart virsh still does not work (I am not sure but I cannot restart my production servers right now). Everything is fine when I run virsh as root. I have the same issue on 7 machines. regards M. Galkiewicz
Hi Maciej, On 04/26/2011 09:13 AM Maciej Gałkiewicz wrote:
I have a problem with virsh. I'm using eucalyptus software on top of xen 4 (debian squeeze). The problem is that unix user "eucalyptus" cannot see vm machines when it executes "virsh list". My libvirt version is 0.8.8-3 from debian sid repository. The same problem occurs with older versions. What is more I have tried to change unix_sock_ro_perms to "2777". After libvirt restart it started to work. Even when I reverted this change it was still working. Unfortunately after server restart virsh still does not work (I am not sure but I cannot restart my production servers right now). Everything is fine when I run virsh as root. I have the same issue on 7 machines.
have you tried a different connection URI?: --------------<----------------- $ virsh -c qemu:///system 'list' -------------->----------------- If not explicitly stated, the virsh binary uses the 'qemu:///session' URI (at least under debian). See also .. VIRSH(1): ----------------------------------<--------------------------------------- qemu:///system "connect locally as root to the daemon supervising QEmu and KVM domains" qemu:///session "connect locally as a normal user to his own set of QEmu and KVM domains" ---------------------------------->--------------------------------------- Please note that in order for the 'qemu:///system' URI to work probably the user must be part of the 'libvirt' group. This way you won't have to touch the permission set of any of the respective sockets. I hope this helps ;) Cheers Jan
2011/4/26 Jan <jan@agetty.de>
have you tried a different connection URI?:
--------------<----------------- $ virsh -c qemu:///system 'list' -------------->-----------------
If not explicitly stated, the virsh binary uses the 'qemu:///session' URI (at least under debian).
See also .. VIRSH(1):
----------------------------------<--------------------------------------- qemu:///system "connect locally as root to the daemon supervising QEmu and KVM domains"
qemu:///session "connect locally as a normal user to his own set of QEmu and KVM domains" ---------------------------------->---------------------------------------
Please note that in order for the 'qemu:///system' URI to work probably the user must be part of the 'libvirt' group. This way you won't have to touch the permission set of any of the respective sockets.
My user is in libvirt group $ id uid=107(eucalyptus) gid=112(eucalyptus) groups=112(eucalyptus),110(libvirt) I have tried 'virsh -c qemu:///system 'list'' as well. Still does not work. regards Maciej
Hi Maciej, On 04/27/2011 09:28 AM Maciej Gałkiewicz wrote: [...]
Please note that in order for the 'qemu:///system' URI to work probably the user must be part of the 'libvirt' group. This way you won't have to touch the permission set of any of the respective sockets.
My user is in libvirt group $ id uid=107(eucalyptus) gid=112(eucalyptus) groups=112(eucalyptus),110(libvirt)
I have tried 'virsh -c qemu:///system 'list'' as well. Still does not work.
so far so good. So what about the output? Do you get any exceptions or errors? If no virtual machines are up and running at the moment you will still have to specify the "--all" parameter in order to list also offline machines: $ virsh -c qemu:///system 'list --all' Maybe you could just try to run virsh in debug mode and figure out whats happening when errors arise: $ export LIBVIRT_DEBUG=1; $ virsh -c qemu:///system 'list' Cheers Jan
2011/4/27 Jan <jan@agetty.de>
so far so good. So what about the output? Do you get any exceptions or errors? If no virtual machines are up and running at the moment you will still have to specify the "--all" parameter in order to list also offline machines:
$ virsh -c qemu:///system 'list --all'
Maybe you could just try to run virsh in debug mode and figure out whats happening when errors arise:
$ export LIBVIRT_DEBUG=1; $ virsh -c qemu:///system 'list'
I realized that this URI is not appropriate for my xen. I have tried as root: # virsh -c xen:/// list Id Name State ---------------------------------- 0 Domain-0 running 14 i-4E8D088D idle As user eucalyptus: $ virsh -c xen:/// list Id Name State ---------------------------------- And as user eucalyptus with debug mode I got sth like this: 12:07:43.032: 22147: debug : xenUnifiedOpen:335 : Trying XenD sub-driver 12:07:43.032: 22147: debug : xenUnifiedOpen:364 : Handing off for remote driver 12:07:43.032: 22147: debug : xenUnifiedOpen:393 : Failed to activate a mandatory sub-driver Do you need more output? regards Maciej
On 04/27/2011 12:11 PM Maciej Gałkiewicz wrote:
I realized that this URI is not appropriate for my xen. I have tried as
Sorry, I'm sticking with kvm for quiet some time now and haven't been using xen for a while.
root: # virsh -c xen:/// list Id Name State ---------------------------------- 0 Domain-0 running 14 i-4E8D088D idle
As user eucalyptus: $ virsh -c xen:/// list Id Name State ----------------------------------
And as user eucalyptus with debug mode I got sth like this: 12:07:43.032: 22147: debug : xenUnifiedOpen:335 : Trying XenD sub-driver 12:07:43.032: 22147: debug : xenUnifiedOpen:364 : Handing off for remote driver 12:07:43.032: 22147: debug : xenUnifiedOpen:393 : Failed to activate a mandatory sub-driver
Could you please have a look at the permissions of the xend sockets under /var/run/xend/*? Since virsh is being executed with the the privileges of the currently logged on user, the driver might not be able to access the respective socket for reading which causes the driver .
2011/4/27 Jan <jan@agetty.de>
Could you please have a look at the permissions of the xend sockets under /var/run/xend/*? Since virsh is being executed with the the privileges of the currently logged on user, the driver might not be able to access the respective socket for reading which causes the driver .
# ls -la total 4.0K drwx------ 3 root root 54 Apr 3 07:09 . drwxr-xr-x 19 root root 4.0K Apr 26 00:18 .. drwx------ 2 root root 6 Nov 24 15:56 boot srwxr-xr-x 1 root root 0 Apr 3 07:09 xen-api.sock srwxr-xr-x 1 root root 0 Apr 3 07:09 xmlrpc.sock regards Maciej
2011/4/27 Maciej Gałkiewicz <maciej.galkiewicz@gmail.com>
2011/4/27 Jan <jan@agetty.de>
Could you please have a look at the permissions of the xend sockets under /var/run/xend/*? Since virsh is being executed with the the privileges of the currently logged on user, the driver might not be able to access the respective socket for reading which causes the driver .
# ls -la total 4.0K drwx------ 3 root root 54 Apr 3 07:09 . drwxr-xr-x 19 root root 4.0K Apr 26 00:18 .. drwx------ 2 root root 6 Nov 24 15:56 boot srwxr-xr-x 1 root root 0 Apr 3 07:09 xen-api.sock srwxr-xr-x 1 root root 0 Apr 3 07:09 xmlrpc.sock
Any ideas? I am stuck. Maciej
participants (2)
-
Jan -
Maciej Gałkiewicz