CentOS virt - Mar 2010 - unable to get domain status from libvirt & KVM

I have a python script that monitors the VMs on physical host servers 
running Xen, but the script doesn't work properly on a server I just 
built with KVM.  The script runs as a non-root user (same on all 
servers) and simply gathers some details on the status and names of the 
domains running on the host.

Both Xen and KVM servers are running the same version of libvirt 
(libvirt-0.6.3-20.1.el5_4) and have the same, default 
/etc/libvirt/libvirtd.conf config file.

To troubleshoot, I've been running python interactively.  Here's how my 
Xen servers behave:

$ python
Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or
"license" for more information.
  >>> import libvirt
  >>> conn = libvirt.openReadOnly(None)
  >>> domains = conn.listDomainsID()
  >>> print domains
[0, 3, 15, 16, 21, 24, 26, 30, 32, 36, 38, 41, 43, 45, 47, 49, 51, 55, 
63, 67]
  >>>

When I try the same thing on the KVM server:

$ python
Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or
"license" for more information.
  >>> import libvirt
  >>> conn = libvirt.openReadOnly(None)
14:33:07.303: error : No vport operation path found for host0
14:33:07.320: error : No vport operation path found for host4
14:33:07.325: error : No vport operation path found for host3
14:33:07.367: error : No vport operation path found for host1
14:33:07.368: error : No vport operation path found for host2
  >>> domains = conn.listDomainsID()
  >>> print domains
[]
  >>>

(The vport stuff is weird, but I found this posting that suggests its 
harmless 
(http://www.mail-archive.com/libvir-list at redhat.com/msg17477.html) so 
I'm ignoring it.)

However, when logged in as root on the KVM server, it works just like my 
Xen servers:

# python
Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or
"license" for more information.
  >>> import libvirt
  >>> conn = libvirt.openReadOnly(None)
  >>> domains = conn.listDomainsID()
  >>> print domains
[1]

Again, on the KVM server, plain old "virsh list" with the debug level 
set to "2"

$ export LIBVIRT_DEBUG=2
$ virsh list
14:21:06.532: error : No vport operation path found for host0
14:21:06.550: error : No vport operation path found for host4
14:21:06.555: error : No vport operation path found for host3
14:21:06.598: error : No vport operation path found for host1
14:21:06.599: error : No vport operation path found for host2
14:21:06.615: info : No security driver available
   Id Name                 State
----------------------------------

Permissions in /var/run/libvirt:

# ls -ld /var/run/libvirt/*
srwx------ 1 root root    0 Feb  5 08:53 /var/run/libvirt/libvirt-sock
srwxrwxrwx 1 root root    0 Feb  5 08:53 /var/run/libvirt/libvirt-sock-ro
drwxr-xr-x 2 root root 4096 Jan 21 14:38 /var/run/libvirt/network
drwxr-xr-x 2 root root 4096 Oct 20 18:50 /var/run/libvirt/qemu

Can someone provide some tips on what else I can check, if this might be 
a bug, or point out any mistakes that I might've made?  Any help is 
appreciated.

Thanks,
Tom

----- "Tom Georgoulias" <tomg at mcclatchyinteractive.com>
wrote:
> Permissions in /var/run/libvirt:
> 
> # ls -ld /var/run/libvirt/*
> srwx------ 1 root root    0 Feb  5 08:53
> /var/run/libvirt/libvirt-sock
> srwxrwxrwx 1 root root    0 Feb  5 08:53
> /var/run/libvirt/libvirt-sock-ro
> drwxr-xr-x 2 root root 4096 Jan 21 14:38 /var/run/libvirt/network
> drwxr-xr-x 2 root root 4096 Oct 20 18:50 /var/run/libvirt/qemu
> 
> Can someone provide some tips on what else I can check, if this might be 
> a bug, or point out any mistakes that I might've made?  Any help is 
> appreciated.
SELinux?

-- 
Christopher G. Stach II
http://ldsys.net/~cgs/

Hi Tom,

As someone who suggested to you that you should try this mailing list,
I would like to quote some of the discussions that have taken place in
the main mailing list (
http://lists.centos.org/pipermail/centos/2010-March/091654.html ).
> $ export LIBVIRT_DEBUG=2
> $ virsh list
> 14:21:06.532: error : No vport operation path found for host0
> 14:21:06.550: error : No vport operation path found for host4
> 14:21:06.555: error : No vport operation path found for host3
> 14:21:06.598: error : No vport operation path found for host1
> 14:21:06.599: error : No vport operation path found for host2
> 14:21:06.615: info : No security driver available
> ? Id Name ? ? ? ? ? ? ? ? State
> ----------------------------------
This is empty because, as a non-root user, you are looking at
qemu:///session instead of  qemu:///system. To be able to access the
latter, you would need to do some tweaking.

I wrote:
[quote]
Look into /etc/libvirt/libvirtd.conf and check out the section "UNIX
socket access controls" and make appropriate adjustment.  [ I created
group 'libvirt' , added myself to the group, and uncommented the line
"unix_sock_group = "libvirt"".]  Then adjust also the
permission bits
of the directories and files in /var/run/libvirt to allow access to
the group libvirt.

With some luck, you should be able to run the virsh command (for example):

virsh -c qemu:///system list --all
[/quote]

Then you wrote:
[quote]
I read about that on libvirt.org but chose not to make any changes
since the Xen server already works with the same config I have on the
KVM server.  I understood libvirt to be a layer that lets one compatible
tool work with many different hypervisors, so I didn't think I'd need to
change my libvirt config to work with KVM if it already works with Xen.
  That might be a bad assumption, though, and I'm not wedded to it.  :)
[/quote]

This is understandable. However, xen and kvm are different in certain
places. For instance, /var/run/libvirt/qemu is unique to kvm, so
making changes to this should not affect your xen configuration. <-
someone please confirm this.

I wrote:
[quote]
Also, if you create a guest with the -c qemu:///session option, that
would allow non-root user to connect to it.
[/quote]

My understanding is that with the -c qemu:///session option, the guest
will be set up in that user's directory. Therefore, no root privilege
is required.

Comments/help from people who are familiar with kvm welcome. :)

Akemi