Hi Daniel 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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list