Bug 581470 - Failing to provision FV guest [through RHN Satellite] - RHEL 5.5 KS testing
Failing to provision FV guest [through RHN Satellite] - RHEL 5.5 KS testing
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
All Linux
medium Severity high
: rc
: ---
Assigned To: Chris Lalancette
Virtualization Bugs
Depends On:
Blocks: 581474
  Show dependency treegraph
Reported: 2010-04-12 07:02 EDT by Garik Khachikyan
Modified: 2015-01-04 16:57 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-04-19 09:26:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Garik Khachikyan 2010-04-12 07:02:32 EDT
Description of problem:

I have a server registered against my sat 530 and running on Xen kernel (kernel-xen-2.6.18-194.el5)
By giving appropriate entitlements to my server (Virtualization Platform) I want to provision now a new Xen-fullvirt-guest ...
My try of doing it failed with "libvir: Domain Config error : unknown OS type hvm"

More details following below:

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

rpm -qa | grep koan

rpm -qa | grep libvirt

rpm -q redhat-release

How reproducible:
2 from 2 attempts

Steps to Reproduce:
1. Register RHEL 5.4 server to Satellite 530 running Xen [it also failed against RHEL 5.5]
2. Make a kickstart profile in satellite to provision "Xen Fully-Virualized-Guest" of RHEL 5.5
3. Entitle the registered client to have "Virtualization Platform"
4. Make a new guest setup by selecting that KS profile through "Virtualization->Provisioning" of that client.
5. run rhn_check -vvv on server side to see the progress. [beforehand libvirtd and xend services should be started]
Actual results:
D: do_call kickstart_guest.initiate ('smqa-r210-03.lab.eng.brq.redhat.com', 'gkhachik-dell-pe2550-01:1:gkh-fv-guest-base-2', 'xenfv', 167, 'gkh-fv-guest-base-2', 512, 1, 3, 'xenbr1', '/var/lib/xen/images/gkh-fv-guest-base-2', ' ')
- looking for Cobbler at http://smqa-r210-03.lab.eng.brq.redhat.com/cobbler_api
- reading URL: http://smqa-r210-03.lab.eng.brq.redhat.com/cblr/svc/op/ks/system/gkhachik-dell-pe2550-01:1:gkh-fv-guest-base-2
install_tree: http://smqa-r210-03.lab.eng.brq.redhat.com/ty/uvo8m4Zv
libvirtd (pid  31400) is running...
- fullvirt mode
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByUUID
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
libvir: Domain Config error : unknown OS type hvm
unknown OS type hvm
  File "/usr/share/rhn/spacewalkkoan/spacewalkkoan.py", line 191, in initiate_guest
   File "/usr/lib/python2.4/site-packages/koan/app.py", line 312, in run
   File "/usr/lib/python2.4/site-packages/koan/app.py", line 601, in virt
    return self.net_install(after_download)
   File "/usr/lib/python2.4/site-packages/koan/app.py", line 520, in net_install
    after_download(self, profile_data)
   File "/usr/lib/python2.4/site-packages/koan/app.py", line 599, in after_download
   File "/usr/lib/python2.4/site-packages/koan/app.py", line 1080, in virt_net_install
    virt_type     =  self.virt_type
   File "/usr/lib/python2.4/site-packages/koan/xencreate.py", line 184, in start_install
   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
   File "/usr/lib/python2.4/site-packages/libvirt.py", line 974, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)

D: Sending back response (1, 'Virtual kickstart failed. Koan error.', {'koan': 'unknown OS type hvm   File "/usr/share/rhn/spacewalkkoan/spacewalkkoan.py", line 191, in initiate_guest\n    k.run()\n   File "/usr/lib/python2.4/site-packages/koan/app.py", line 312, in run\n    self.virt()\n   File "/usr/lib/python2.4/site-packages/koan/app.py", line 601, in virt\n    return self.net_install(after_download)\n   File "/usr/lib/python2.4/site-packages/koan/app.py", line 520, in net_install\n    after_download(self, profile_data)\n   File "/usr/lib/python2.4/site-packages/koan/app.py", line 599, in after_download\n    self.virt_net_install(profile_data)\n   File "/usr/lib/python2.4/site-packages/koan/app.py", line 1080, in virt_net_install\n    virt_type     =  self.virt_type\n   File "/usr/lib/python2.4/site-packages/koan/xencreate.py", line 184, in start_install\n    guest.start_install()\n   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in start_install\n    return self._do_install(consolecb, meter, removeOld, wait)\n   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in _do_install\n    self.domain = self.conn.createLinux(install_xml, 0)\n   File "/usr/lib/python2.4/site-packages/libvirt.py", line 974, in createLinux\n    if ret is None:raise libvirtError(\'virDomainCreateLinux() failed\', conn=self)\n'})

Expected results:
Should not fail on initiation.

Additional info:
Comment 1 Garik Khachikyan 2010-04-12 07:04:04 EDT

Not sure, but I assume that I hit the issue: bug#509337
Comment 3 Petr Sklenar 2010-04-13 04:21:59 EDT
I tried the same for ia64 full guest a I could see the same issue
Comment 4 Justin Sherrill 2010-04-15 14:34:51 EDT
So here is the XML we are passing to createLinux()  (through python-virtinst)

<domain type='xen'>
    <boot dev='network'/>
  <clock offset="utc"/>
    <console type='pty'/>
    <disk type='file' device='disk'>
      <source file='/var/lib/xen/images/jlsherri2'/>
      <target dev='hda' bus='ide'/>
    <interface type='bridge'>
      <source bridge='xenbr0'/>
      <mac address='00:16:3e:33:94:6b'/>
    <input type='mouse' bus='ps2'/>
Comment 5 Justin Sherrill 2010-04-15 17:04:26 EDT
Also recreated by simply putting the above XML in a file and running   virsh create ~/file.xml
Comment 6 Garik Khachikyan 2010-04-16 09:02:27 EDT

One note: did not check if in BIOS the hardware virtualization is turned on...

Will be requesting if it's possible to put it our rlx-* systems and will make one more try.

@Justin: where is the location of that xml in the host server actually - in order to extract and see its content.

Comment 7 Jan Hutař 2010-04-16 09:44:42 EDT
I was able to reproduce this on the full-virt not-capable system. Are you sure you are testing on the full-virt capable system?


# grep -e vmx -e svm /proc/cpuinfo

Should produce something.
Comment 8 Chris Lalancette 2010-04-16 11:27:41 EDT
Note that the presence of the vmx or svm flag is required, but not sufficient.  Many machines ship with the fully virt extensions disabled in the BIOS.  Your best bet is to run "virsh capabilities" and see if it shows HVM.  If not, then it is probably disabled in the BIOS.

Chris Lalancette
Comment 9 Justin Sherrill 2010-04-16 11:29:22 EDT
The machine that Garik was initially using (dell-pe2550-01.rhts.eng.bos.redhat.com) doesn't appear to be fully virt capable. 

Garik,  To get that XML, i actually had to modify python-virtinst to print it out.  (had done it as part of my debugging).
Comment 10 Justin Sherrill 2010-04-16 11:30:54 EDT
Garik,  Our rlx-* systems aren't fully virt capable either.  We have a couple in the rhn lab I believe, so feel free to ping me about it.
Comment 11 Garik Khachikyan 2010-04-19 05:04:36 EDT

No need to apply any fix here: as I was provided by a full-virt capable server and KS 5.5 with Xen full-virt option just went ok without any problem.

So the issue could be considered as invalid. thanks.
Comment 12 Chris Lalancette 2010-04-19 09:26:59 EDT
OK, thanks for testing.  Closing.

Chris Lalancette

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