Bug 510695 - Kernel 2.6.28-13 exposes interface causing libvirt to provide bad arguments to kvm and lock up win32 guest
Summary: Kernel 2.6.28-13 exposes interface causing libvirt to provide bad arguments t...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-10 10:01 UTC by James Hogarth
Modified: 2010-03-16 17:21 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-30 11:58:21 UTC
Embargoed:


Attachments (Terms of Use)

Description James Hogarth 2009-07-10 10:01:25 UTC
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.

Comment 1 Daniel Berrangé 2009-07-30 11:58:21 UTC
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

https://bugzilla.redhat.com/show_bug.cgi?id=499596


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