Bug 510695 - Kernel 2.6.28-13 exposes interface causing libvirt to provide bad arguments to kvm and lock up win32 guest
Kernel 2.6.28-13 exposes interface causing libvirt to provide bad arguments t...
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Daniel Veillard
Depends On:
  Show dependency treegraph
Reported: 2009-07-10 06:01 EDT by James Hogarth
Modified: 2010-03-16 13:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-30 07:58:21 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 James Hogarth 2009-07-10 06:01:25 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 -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.
Comment 1 Daniel Berrange 2009-07-30 07:58:21 EDT
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


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