Hello,

I have an old Win XP VM that I occasionally need. It is managed by libvirt and virt-manager.
It no longer boots with kvm enabled. I guess the update from Debian stretch to buster broke something (I cannot tell for sure when it broke, because I rarely use it).

A little investigation revealed that I can start the VM manually from the command line with:
If I call it with --enable-kvm like so:
Windows stops booting after the line
multi(0)disk(0)rdisk(0)partition(1)\Windows\System32\Drivers\Mup.sys and then offers to boot into safe mode (which does not work either).

Similarly the VM boots with option -machine pc-1.1,accel=tgz,... and it fails with -machine pc-1.1,accel=kvm,...
So I changed the XML definition of the VM in /etc/libvirt/qemu and replaced <domain type='kvm'> with <domain type='qemu'> and also the emulator-tag to qemu-system-x86_64.
Now the VM can be started from virt-manager - but

Why does an existing Windows XP VM no longer work with kvm?
What changed here? Is this intentional? Bug or feature?

How can I find out more about the issue? I did not find any errors in the logs in /var/log/libvirt/qemu. The host seems completely unaware that the guest has a problem.

"\Mup.sys"

You can't easily move windows. Mup is saying that the machine was created on a system that is now not the same. Either fix hal or return to original hal.

Hi Jefro,

Thank you for your answer.

Just to make sure we are on the same page:

I have not changed the VM, the VM definition in /etc/libvirt/qemu, the Windows XP installation on it, the CPU of the host, the BIOS settings of the host, or the settings for libvirtd in /etc/libvirt.
The only thing that changed is the upgrade of the host to Debian buster.
So the version of the package qemu-kvm has changed, and the new kvm apparently treats the VM differently now, so that Windows believes it is running on a different hardware.

How do I do that?

I do not know what changed in kvm.
Surprisingly the VM runs with kvm disabled (accel=tgz) but not with kvm enabled (accel=kvm), even though it must have run with kvm enabled before the upgrade to buster.
I have checked older backups of the XML definition of the VM in /etc/libvirt/qemu, and the VM has been created and always been used with kvm enabled.

Since one set of command line options work we have to assume that the image you have is at least mostly correct. Since it replies with mup.sys I usually assume hal. Plenty of web articles how to fix hal on windows xp.

Not sure about your build of kvm/qemu and your choices of options. Guess you could start with simply qemu or use 32 bit.

Not sure what changed either. You could downgrade or create new test system. I'd save off this vm image and only use copies while testing. I assume that as each update of a vm program they tend to make it more closely integrated with the host. But some set of hal would be my first guess has changed. There may be some import or export options with other vm's that can fix hal to their vm product.

The normal way to fix has by MS web pages is something like make backup with system state and then reload clean xp to new hardware and then apply backup with system state. (if I recall correctly) See technet.

Some helpful info. https://wiki.archlinux.org/index.php...ualized_system

I think it us fair to say that the image is "proven good beyond doubt".
I have numerous backups of different states of this image for the last 5 years. They all worked, and none does now.
So it has nothing at all to do with the image itself or the Windows installation on it.
Meanwhile I also tried to repair the image using the Windows XP installation CD. Even the CD ends up in a boot loop after "Setup is starting Windows...".

Something has changed in kvm that XP does not cope with.
Qemu works - but using the VM without acceleration is a bit tedious.

So I was hoping there was a compatibility switch that makes 'qemu-system-x86_64 --enable-kvm' behave like it did before: accelerated, but still compatible with Win XP.