Description of problem: Version-Release number of selected component (if applicable): kvm-74-10.fc10.x86_64 virt-manager-0.6.0-5.fc10.x86_64 kernel-2.6.27.9-159.fc10.x86_64 How reproducible: Always after install , though I have not tried reinstalling guest OS. Steps to Reproduce: 1. Install Windows 2000 Server with virt-manger (default networking, 2 of 4 cpus) 2. Start virtual machine (using virt-manager) 3. Let windows run nearly idle Actual results: op - 07:52:33 up 1 day, 20:04, 2 users, load average: 2.03, 2.03, 2.00 Tasks: 131 total, 3 running, 128 sleeping, 0 stopped, 0 zombie Cpu0 : 1.0%us, 2.7%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st Cpu1 : 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st Cpu3 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3092672k total, 2864076k used, 228596k free, 140244k buffers Expected results: Well I would expect the 2 allocated cpu's not running in some sort of "busy idle-loop" Additional info: Windows 2000 Server is running on "MPS Multiprosessor PC"-hal, since this is the end result using virt-manager. I do not know if it possible to install it as ACPI. I found out with google some info about kvm+kernel stuff leading to wrong cpu reporting, but they did not my case since also individual number on cpu's show 100% load.
Created attachment 328974 [details] cat /proc/cpu
Created attachment 328975 [details] log from /var/log/libvirt/qemu
http://sourceforge.net/tracker/index.php?func=detail&aid=2314737&group_id=180599&atid=893831 Seems that one should use acpi with windows 2000. Though one should IMHO still fix virt-manager package to create acpi-quest-environment by default when installing windows 2000 quest. I will try to use acpi (when I will find out how to change the command line options given to kvm with virt-manager)
Try installing the "systat" package and running e.g. "mpstat -P ALL 20 10" for more CPU usage stats. As for trying with ACPI enabled, run "virsh edit MyDomain" and add "<acpi/>" to the <features> section
Closing bug, since issue with Windows 2000 running with kvm, i.e. is matter of UPSTREAM/Redmont.
So, enabling ACPI fixed the problem? And you selected "Windows 2000" when creating the guest in virt-manager? If so, we should consider enabling ACPI for Windows 2000 guests by default In python-virtinst, we have: "win2k": { "label": "Microsoft Windows 2000", "acpi": False, "apic": False },
Today I installed Windows 2000 server (SP4) again and selected "Windows 2003" as a quest to be installed. It installed just fine (this leads to acpi=1 apic=1 I think) and the quest is currently running without any problems. CPU now idles as one should expect (Windows gives HALT-command or whatever it is called, and busy loop is not a problem any more.) And I think that shutting down the quest works even better than without acpi. (Well even with "real" Windows shutting down is always a adventure (explorer crashes , saving settings etc ;-)) So at least with Windows 2000 SP4 Server and the current kvm version acpi-hal seems to work even during install on Windows quest side. Though I can not test with CDs with older service packs.
Just a small correction to the previous message. W2k Server SP4 crashes once during install when acpi=1 and apic=1. 1) "Blue screen" at the end of second reboot during the install. Install was done with cd-image on hd. (And yes I did not realize to take screen shot of the bs of death :( ) 2) However, when one restarts quest machine, the install continues as expected. And now I have had two quest W2k Servers running (>24h) in same server using acpi and no crashes yet. (Though they only ping each other, so not running heavy application loads yet) (Anyway, if I will have any problems with the quests in the future, I will try kvm-83-1.fc11.x86_64.rpm (or never) if it runs with fc-10 kernel)
Second Note: If one installs "Update Rollup 1" for Windows 2000 SP4 (for example by updating with Windows update.) ..then this busy loop problem returns even on acpi-quests !!!! See this link to fix it: http://support.microsoft.com/default.aspx?scid=kb;EN-US;919521 (I am already running kvm-83-1.fc11.x86_64.rpm , but the link should be valid fix for "Update Rollup 1"-problem also in kvm-74 or xen etc..
This is fixed in latest virtinst: we enable acpi/apic for windows XP for all hypervisors except xen < 3.1.0 (which prompted the original acpi settings). However, this would require a pretty invasive backport to get the infrastructure set up: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/shortlog/3c68ba7758a6 http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/3c68ba7758a6 So not F-10 material at this point. Moving to F11.
python-virtinst-0.400.3-11.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/python-virtinst-0.400.3-11.fc11
python-virtinst-0.400.3-11.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update python-virtinst'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10356
python-virtinst-0.400.3-11.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.