+++ This bug was initially created as a clone of Bug #211244 +++ Description of problem: If you try to use virt-manager or xenguest-install to install a new XEN guest it fails when it tries to do the install. [root@dhcp59-101 ~]# xenguest-install Would you like a fully virtualized guest (yes or no)? This will allow you to run unmodified operating systems. yes What is the name of your virtual machine? system1 How much RAM should be allocated (in megabytes)? 256 What would you like to use as the disk (path)? /dev/my_test_vg/xen_store1 Would you like to enable graphics support? (yes or no) yes What would you like to use for the virtual CD image? /mnt/archives/released/RHEL-4/U4/AS/x86_64/RHEL4-U4-re20060802.1-x86_64-AS-DVD-ftp.iso Starting install... libvir: Xen Daemon error : GET operation failed: No such domain system1 libvir: Xen Daemon error : POST operation failed: (xend.err 'Error creating domain: HVM guest support is unavailable: is VT/AMD-V supported by your CPU and enabled in your BIOS?') Failed to create domain system1 Traceback (most recent call last): File "/usr/sbin/xenguest-install", line 396, in ? main() File "/usr/sbin/xenguest-install", line 360, in main dom = guest.start_install(conscb) File "/usr/lib/python2.4/site-packages/virtinst/XenGuest.py", line 355, in start_install self.domain = self.conn.createLinux(cxml, 0) File "/usr/lib64/python2.4/site-packages/libvirt.py", line 249, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed') libvirt.libvirtError: virDomainCreateLinux() failed Version-Release number of selected component (if applicable): [root@dhcp59-101 ~]# rpm -q libvirt libvirt-python xen libvirt-0.1.8-1 libvirt-python-0.1.8-1 xen-3.0.3-0.1.rc3 How reproducible: Always Steps to Reproduce: 1.Try to create a new xen guest using xenguest-install or virt-manager 2. 3. Actual results: You get an error message, or a traceback in the case of xenguest-install Expected results: Should continue with the install Additional info: -- Additional comment from jwhiter on 2006-10-17 22:09 EST -- ahh ok well i just actually read the traceback so I assume its happening b/c I select "Fully Virtualized" and it says I dont ahve the capabilities, but I do [jwhiter@dhcp59-101 ~]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Genuine Intel(R) CPU @ 1.86GHz stepping : 5 cpu MHz : 1861.965 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 4656.60 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: I have the vmx flag which is the flag i need for it to be fully virtualized right? -- Additional comment from berrange on 2006-10-18 08:30 EST -- As per the error message shown in comment #1, merely having VMX flag in the CPU is not sufficient. You must also ensure it is enable in the BIOS. That said, the 'virtinst' package should be checking this too - the code only checks the CPU flags currently, but should also check the MSR, or xen capabilities flags & not traceback.
We can get this info from sysfs: # cat /sys/hypervisor/properties/capabilities xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p Which looks like it is accurate wrt to BIOS settings for VMX/AMD-V (if I disable VMX in the BIOS, the hvm-* capabilities go away)
Seems like a reasonable way to check -- committed
Since we have this and it's something that's a bit confusing to people, we might as well fix for b2
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering. This request is not yet committed for inclusion in release.
QE ack for RHEL5B2.