Univention Bugzilla – Bug 30413
installation of windows 8 32bit not possible with kvm
Last modified: 2013-11-19 06:43:25 CET
It seems that it is not possible to install Windows 8 32bit with the use of libvirt at the moment: https://bugzilla.redhat.com/show_bug.cgi?id=907556 I am facing this issue too at least at krus.
https://bugzilla.redhat.com/show_bug.cgi?id=832301 https://bugzilla.redhat.com/show_bug.cgi?id=821741
<domain type='kvm'> <name>tpeterse_win8-32</name> <uuid>fff89fad-67d2-c759-f0b0-e4ff624999aa</uuid> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-1.1'>hvm</type> <boot dev='cdrom'/> <boot dev='hd'/> </os> <features> <acpi/> <apic/> </features> <clock offset='localtime'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> [...]
Created attachment 5076 [details] screenshot of failure message
It works on isala - seems to be related to the host cpu krus: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid isala: AMD Opteron(tm) Processor 6128 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save pausefilter
By default libvirt starts the VM with cpu=qemu64, even 32 bit VMs (Bug #21860, Bug #21383). This is what the non-KVM-accelerated TCG implements and is used to provide maximum portability: Any feature missing on the host CPU could possibly be emulated by the TCG. This is important when migrating VMs between hosts with (slightly) different CPUs. Setting the CPU model only modifies what the "CPUID" instruction exports to the guest OS; it *does* *not* disable CPU instructions, so any OS can still use them. Normally OSs and applications call the CPUID instruction first to check, which CPU features are available and then branch to the right implementation. Windows seems to do this too, but gets confused by what QEMU exports. Here's my simple test call to check different CPU models: /usr/bin/kvm -enable-kvm -m 1024 -snapshot -sdl -cdrom /mnt/omar/vmwares/kvm/iso/windows/Windows_8_Pro_32bit_English_X18-15874.iso -hda /var/lib/libvirt/images/phahn_win8-0. -cpu $CPU It works with CPU=kvm64, but not with the default CPU=qemu64. The difference in CPUID output can be described as kvm := qemu64,+popcnt,+sse4a,+abm,+svm,+lahf_lm,family=15,model=6,level=5,vendor="GenuineIntel" # -popcnt,-lahf_lm,stepping=1 Removing one difference after another I was able to trim it down to the following required minimum: qemu64,family=15 There was this patch <http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg03629.html>, which updates the model number, but was rejected upstream. The mail thread contains more details. The too low family number probably confused the CPUID detecting routine of the Windows installer, which takes the wrong branch based on that information and then aborts with the NX feature missing. (Here is one good posts about the Windows installer: <http://answers.microsoft.com/en-us/windows/forum/windows_install/error-when-installing-windows-8-release-preview/a2c11f2c-d43b-44fc-9bc0-61805a2d95ef>) The Intel families are described here: <http://software.intel.com/en-us/articles/intel-architecture-and-processor-identification-with-cpuid-model-and-family-numbers>. We (Univention) have multiple options: 1. Changing the default of qemu64 to include family=15 can break existing VMs and migration between QEMU versions. 2. Setting /domain/cpu/model=host in the domain XML would export all CPU features to all VMs, which can break migration between hosts with (slightly) different CPUS. 3. Update to a newer QEMU version; 1.6.0+dfsg-1 from Debian works. As any change can break existing VMs, we won't change the default, but provide a workaround. Users wishing to install Windows 8 32 bit on QEMU are advised to modify the domain XML to include the following snippet until Bug #21386 is implemented. This will pass through all host features, which gives maximum performance, but can be problematic for migration: <domain type='kvm'> ... <cpu mode='host-model'> <model fallback='allow'/> </cpu> ... </domain> If migration is critical, something like the following should be used instead: ... <cpu mode='custom' match='exact'> <model fallback='allow'>kvm64</model> </cpu> (Other possible models are listed in the file /usr/share/libvirt/cpu_map.xml) For more details see <http://libvirt.org/formatdomain.html#elementsCPU>
Created attachment 5411 [details] Test-script to test different QEMU CPU models The script creates an InitRamFS, which just dumps /proc/cpuinfo to the console.
OK
UCS 3.2 has been released: http://docs.univention.de/release-notes-3.2-en.html http://docs.univention.de/release-notes-3.2-de.html If this error occurs again, please use "Clone This Bug".