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 koan-1.6.8-4.el5sat spacewalk-koan-0.1.11-13.el5sat rpm -qa | grep libvirt libvirt-0.6.3-33.el5 libvirt-python-0.6.3-33.el5 rpm -q redhat-release redhat-release-5Server-5.4.0.3 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 libvirt.libvirtError unknown OS type hvm File "/usr/share/rhn/spacewalkkoan/spacewalkkoan.py", line 191, in initiate_guest k.run() File "/usr/lib/python2.4/site-packages/koan/app.py", line 312, in run self.virt() 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 self.virt_net_install(profile_data) 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 guest.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 Not sure, but I assume that I hit the issue: bug#509337
I tried the same for ia64 full guest a I could see the same issue
So here is the XML we are passing to createLinux() (through python-virtinst) <domain type='xen'> <name>jlsherri2</name> <currentMemory>524288</currentMemory> <memory>524288</memory> <uuid>b4c20f38-51c9-5cb6-32fb-fa7af85264c2</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='network'/> </os> <features> <acpi/><apic/><pae/> </features> <clock offset="utc"/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <vcpu>1</vcpu> <devices> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <console type='pty'/> <disk type='file' device='disk'> <source file='/var/lib/xen/images/jlsherri2'/> <target dev='hda' bus='ide'/> </disk> <interface type='bridge'> <source bridge='xenbr0'/> <mac address='00:16:3e:33:94:6b'/> </interface> <input type='mouse' bus='ps2'/> </devices> </domain>
Also recreated by simply putting the above XML in a file and running virsh create ~/file.xml
# COMMENT 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. Thanks.
Hello, 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? http://fedoraproject.org/wiki/Virtualization_Quick_Start#Additional_requirements_for_fully_virtualized_guests # grep -e vmx -e svm /proc/cpuinfo Should produce something.
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
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).
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 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.
OK, thanks for testing. Closing. Chris Lalancette