Thanks for getting back to me. The permissions on that directory look ok
to me, see below (cadc is the group specified in my libvirtd.conf).
Which leads me to think it could be something else.
labrosse@proc5-09$ ls -la /var/run/libvirt
total 16
drwxr-xr-x 2 root root 4096 Apr 15 03:25 .
drwxr-xr-x 21 root root 4096 Apr 15 04:02 ..
srwxrwx--- 1 root cadc 0 Apr 15 03:25 libvirt-sock
srwxrwxrwx 1 root cadc 0 Apr 15 03:25 libvirt-sock-ro
labrosse@proc5-09$ ls -l /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root cadc 0 Apr 15 03:25 /var/run/libvirt/libvirt-sock
It seems as if its xen causing the issue (although i cannot see any
issues in the logs). I get a 'Xen Daemon error' when connecting as my
user. I have verified the xen daemon is running and I can sudo virsh
list without seeing any errors.
labrosse@proc5-09$ virsh list
libvir: Xen Daemon error : internal error failed to connect to xend
libvir: Xen Daemon error : internal error failed to connect to xend
Id Name State
----------------------------------
0 Domain-0 running
7 1-d462220a-8dfe-4b7b-b853-a89f3cac2d46 blocked
labrosse@proc5-09$ sudo virsh list
Id Name State
----------------------------------
0 Domain-0 running
7 1-d462220a-8dfe-4b7b-b853-a89f3cac2d46 blocked
Are you aware of any other configuration that needs to be done elsewhere?
thanks
Daniel
On Wed, 2009-04-15 at 10:08 +0100, Daniel P. Berrange wrote:
On Tue, Apr 14, 2009 at 02:06:52PM -0700, Daniel Labrosse wrote:
> Hi All,
>
> I've been using libvirt 0..4.4 for a few weeks now. I have
> unix_sock_group = "mygroup" set so that i can perform non-root
> management capabilities on the host.
>
> I have recently installed a new host running Scientific Linux 5.3 and
> libvirt 0.3.3 comes as default. First off, there is no libvirtd.conf
> file included with 0.3.3, so I copied the file from libvirt 0.4.4 (which
> is running on my Fedora 8 box).
The 'unix_sock_group' config param *is* supported in 0.3.3, but the
libvirtd daemon will not change the group ownership in the directory
/var/run/libvirt where the socket is created. So you almost certainly
won't be able to access the socket itself. You could try chgrp'ing the
directory. A good test is to make sure you can access the socket as
non-root, eg
ls -l /var/run/libvirt/libvirt-sock
Daniel