Bug 199651 - listDomainsID() returns bogus values in Xen 3.0.1
listDomainsID() returns bogus values in Xen 3.0.1
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-20 23:01 EDT by Pete Vetere
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.