[Libvir] Bug with libvirt in Xen 3.0.1?

[Daniel Veillard]

On Thu, Jul 20, 2006 at 09:16:16AM -0400, pvetere at redhat.com wrote:
> Hi, I think I may have found a bug in libvirt and wanted see what people
> thought.  I'm using the stock FC5 installation at the moment (with xen 3.0.1),
> and the newest version of libvirt.  I am noticing that with xen 3.0.1 and newer
> versions of libvirt, getDomainsID() seems to return bogus values.  For example:
> 
> [root at test05 ~]# virsh list
>  Id Name                 State
> ----------------------------------
>   0 Domain-0             running
> libvir: Xen Daemon error : GET operation failed: No such domain 65486
> libvir: Xen Daemon error : GET operation failed: No such domain 2986
> 
> But, if I use xm, I get what I expect:
> 
> [root at test05 ~]# xm list
> Name                              ID Mem(MiB) VCPUs State  Time(s)
> Domain-0                           0     1507     2 r-----   387.5
> vm1                                1      256     1 -b----   151.3
> vm2                                2      256     1 -b----    87.9
> 
> After some digging around in the code, I believe that libvirt is incorrectly
> identifying the hypervisor as being "old" in xen_internal.c:xenHypervisorInit,
> and is therefore passing the incorrect parameter structure into the hypervisor
> when it makes its ioctl in xen_internal.c:xenHypervisorListDomains.

  I assume it's an i386 platform, because the ABI breakage should not
show up on x86_64.

> I've tried this same test on a system running xen 3.0.2, and as I expected
> everything works fine.  So, there must be something different about xen 3.0.1
> that libvirt is not accounting for.

  That's possible. If you still have that setup around, could you rerun 
virsh (as root ) under gdb and put a breakpoint in xenHypervisorInit
and see what's happening in the first hypervisor call values of hc.op and
cmd, and return value (hv_version). Then what's happen in the second call
(is it failing too ?) in that same routine.

> At this point, I don't really have more time to dig further but I thought I'd
> bring up the issue in case someone on this list can offer more insight.

  If you don't have time, that's okay, just bugzilla this so I remember to
have a look at the issue,

  thanks !

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/