Bug 214264 - Operating system type reported incorrectly by proxy
Operating system type reported incorrectly by proxy
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-06 15:15 EST by Daniel Berrange
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: beta2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-22 21:07:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2006-11-06 15:15:19 EST
Description of problem:
When running the 'virsh dominfo' command as an unprivileged user, the operating
system type will always be reported as 'linux', even for HVM guests.

Compare:

# id -u
0
# virsh dominfo demo
Id:             18
Name:           demo
UUID:           4b1df71e-6c27-96b6-4bbd-f7b43d523067
OS Type:        hvm
State:          blocked
CPU(s):         1
CPU time:       63.2s
Max memory:     533680 kB
Used memory:    525488 kB


With

$ id -u
500
$ virsh dominfo demo
Id:             18
Name:           demo
UUID:           4b1df71e-6c27-96b6-4bbd-f7b43d523067
OS Type:        linux
State:          no state
CPU(s):         1
CPU time:       64.4s
Max memory:     533680 kB
Used memory:    525488 kB


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


How reproducible:
Always

Steps to Reproduce:
1. Create an HVM guest
2. Run 'virsh dominfo <guestname>'
3.
  
Actual results:
OS type is 'linux'

Expected results:
OS type is 'hvm'

Additional info:
This also impacts the applet & virt-manager applications, so looks like a bug in
the implemnetation of the setuid proxy daemon used for unprivileged connections
to the HV.
Comment 1 RHEL Product and Program Management 2006-11-06 15:20:32 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 2 Daniel Veillard 2006-11-06 16:58:55 EST
Okay I see the problem. virtGetOsInfo is not following the normal driver
architecture and call directly a routine reading from xenstore, or return
"linux" if this fails.
This call must be properly integrated in the driver blocks, and 2 entry points 
must be provided one for the XenStore module and one for the proxy, then the
proxy code must be extended to provide this new request. Should be fairly simple
but touches a number of modules.

  Will do,

Daniel
Comment 3 Daniel Veillard 2006-11-07 10:36:02 EST
I have just commited a fix for this in libvirt upstream CVS and I have a patch
available. This seems to work for me but it would be good to double check,
Dan can you have a look at it and confirm ?

Daniel
Comment 4 Daniel Berrange 2006-11-07 15:30:57 EST
Its working correctly for para & fully virt guests OS, but its broken for Domain-0:

$ ~/usr/bin/virsh dominfo Domain-0
Id:             0
Name:           Domain-0
UUID:           00000000-0000-0000-0000-000000000000
libvir: error : operation failed: xenProxyDomainGetOSType
OS Type:        linux
State:          running
CPU(s):         2
CPU time:       11270.4s
Max memory:     4294967292 kB
Used memory:    925900 kB

It seems virsh checks for a NULL returned by virDomainGetOSType and hardcodes it
to Linux. This check should really be moved into the virDomainGetOSType backend
itself, because hardcoding to 'linux' is a xen-ism & this would also fix the
error messages seen above.
Comment 5 Daniel Veillard 2006-11-08 08:02:09 EST
Okay I fixed all this, this should work correctly now, I checked as user and
root for domain 0,

Daniel
Comment 6 Daniel Veillard 2006-11-22 09:04:26 EST
This has been commited in libvirt upstream,

Daniel
Comment 7 Jay Turner 2006-12-06 22:44:31 EST
QE ack for RHEL5.
Comment 8 Daniel Veillard 2006-12-07 08:39:59 EST
libvirt-0.1.8-7.el5 has been built carrying the patch, that should fix it !

Daniel
Comment 11 RHEL Product and Program Management 2006-12-22 21:07:56 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

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