2:13 a.m.
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
8:14 a.m.
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
2:28 a.m.
2011/4/26 Jan <jan(a)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
4:55 a.m.
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
5:11 a.m.
2011/4/27 Jan <jan(a)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
5:49 a.m.
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 .
5:53 a.m.
2011/4/27 Jan <jan(a)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
3:09 a.m.
2011/4/27 Maciej Gałkiewicz <maciej.galkiewicz(a)gmail.com>
2011/4/27 Jan <jan(a)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
5011
days inactive
5020
days old
7 comments
2 participants
participants (2)
-
Jan -
Maciej Gałkiewicz