Red Hat Bugzilla – Bug 510695
Kernel 2.6.28-13 exposes interface causing libvirt to provide bad arguments to kvm and lock up win32 guest
Last modified: 2010-03-16 13:21:51 EDT
Description of problem:
This problem was discovered on Ubuntu Jaunty by affects all distributions using libvirt 0.6.1 and kernel 2.6.28-13 (or newer presumably). Libvirt when constructing the arguments passed (using virsh and a domain xml definition) does not include specific cpu instruction expecting kvm-qemu to fall back to system checks and sane defaults (possibly this bug could be logged against KVM QEMU as well/instead of). See the following from the libvirt log output:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/kvm -S -M pc -m 500 -smp 1 -name Outlook -uuid aac072f0-1643-e375-f4c8-880abc123b29 -monitor pty -pidfile /var/run/libvirt/qemu//Outlook.pid -boot c -drive file=/home/james/vms/kvm-outlook/outlook.qcow2,if=ide,index=0,boot=on -net nic,macaddr=52:54:00:c6:55:63,vlan=0 -net tap,fd=16,script=,vlan=0,ifname=vnet0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-gb
The system boots as far as windows text mode and then before showing teh windows graphical boot screen appears to freeze and the virsh/libvirt management tools show the system to peg out the CPU causing teh system to fail to boot. The system will boot if put into safe mode however.
Investigation has shown that instructing kvm/qemu to disable NX within the guest (-cpu qemu32,-nx or -cpu qemu64,-nx) will allow the windows guest to boot to normal mode as per usual.
Libvirt should be modified to ensure that a specific cpu is presented on construction of the kvm command (possibly via an updated cpu definition/optin in the xml?) and/or kvm should have improved checks for NX and disable it if necessary to prevent the guest from working.
My Ubuntu Karmic development guest has no such troubles however so this might possibly be a windows specific work around needed.
After discussions with KVM maintainer, concluded that this is a host kernel bug in KVM, semi-recently fixed in upstream KVM but likely not int he .28 kernel. Recommend that you report it in the Ubuntu bug tracker against kvm/kernel to get it fixed there.
FYI, it sounds like this bug describes the kernel issue you are seeing - see comment #2 in particular