Bug 199651

Summary: listDomainsID() returns bogus values in Xen 3.0.1
Product: [Fedora] Fedora Reporter: Pete Vetere <pvetere>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.1.7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-02 10:55:01 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Pete Vetere 2006-07-20 23:01:43 EDT
Description of problem:

Calling listDomainsID() on a system with Xen 3.0.1 causes bad values to be returned.


Version-Release number of selected component (if applicable):

libvirt 0.1.3


How reproducible:

Always


Steps to Reproduce:
1.  Get a system running Xen 3.0.1.  (FC5's stock install has it)
2.  Install the libvirt 0.1.3
3.  Create a virtual instance or two
4.  Run "virsh list"
  

Actual results:

You'll see some failures in virsh's output, for example:
[root@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


Expected results:

Something analogous to xm's output on the same system:

[root@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


Additional info:

This bug was first identified on libvir-list.  For more info, please see the
related thread in the following URL:

https://www.redhat.com/archives/libvir-list/2006-July/msg00052.html
Comment 1 Pete Vetere 2006-07-20 23:05:21 EDT
For convenience, here is the original message I posted to libvir-list.  I
believe libvirt is incorrectly identifying Xen 3.0.1 as an "old" hypervisor. 
Because of this, it passes the wrong parameter structure into the ioctl and
receives bogus values in return.

-------------------------------------------------------------------------------

    * From: pvetere redhat com
    * To: libvir-list redhat com
    * Subject: [Libvir] Bug with libvirt in Xen 3.0.1?
    * Date: Thu, 20 Jul 2006 09:16:16 -0400

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 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 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'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.

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.

Comment 2 Daniel Veillard 2006-11-02 10:55:01 EST
This has been fixed some time ago, begnning of august IIRC the hypervisor
breakage has been a royal PITA, but that's fixed :-)

Daniel