I recently created a Win XP 32bit VM to test the win32 Bacula file daemon binary.  I used my libvirt on top of Centos5.6 environment for this testing.

[root@apollo3 ~]# uname -rm2.6.18-238.9.1.el5 x86_64[root@apollo3 ~]# yum info virt-managerLoaded plugins: fastestmirror, priorities, securityLoading mirror speeds from cached hostfile * addons: mirror.san.fastserv.com * base: mirror.rocketinternet.net * extras: mirror.rocketinternet.net * updates: mirror.hmc.edu214 packages excluded due to repository priority protectionsInstalled PackagesName       : virt-managerArch       : x86_64Version    : 0.6.1Release    : 13.el5.centosSize       : 5.4 MRepo       : installedSummary    : Virtual Machine ManagerURL        : http://virt-manager.org/License    : GPLv2+Description: Virtual Machine Manager provides a graphical tool for administering           : virtual machines such as Xen. It uses libvirt as the backend           : management API.

I then noticed that the instance was constantly keeping it’s two KVM vcpus at 100% despite the windows task manager claiming the instance was completely idle.  The windows shell was also very responsive through VNC.  After some reasearch, it seems that this problem has been fairly common with win2k/winxp on top of libvirt/KVM.  Eg., Example Google Query It seems that this is actually the fault of the way virt-manager sets the feature flags in the libvirt qemu/KVM configuration file.

When you select “Microsoft Windows XP (x86)” as the OS type it sets the feature flags as:

  <features>
    <pae/>
  </features>

However, for “Microsoft Windows Vista” it sets them as:

  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>

Supposedly, Win* selects it’s HAL layer at install time and this effectively permanently enables/disable APCI support for the platform. Going back and changing the libvirt configuration file and restarting the VM won’t fix it post OS installation.

This forum thread claims that you can change the HAL layer with the boot media. I tried that method twice without resolving the CPU burn problem.

The really odd thing is that this did change the driver listed in the device manager uder “computer” to be the correct “MPS Multiproccessor PC”.  Supposedly, you can change this driver manual to one of the more generic HAL types and this will fix the CPU usage at the cost of disabling SMP support; I wasn’t interested in that solution so I never tried it.  The solution I used was to create a new image with OS Type set to Vista as outlined above.