IRQL_NOT_LESS_OR_EQUAL after moving Windows XP guest to new virtual machine host

I have two Virtual Machine Servers, both are similar spec 64 bit machines, same processor, etc. Both are running KVM with LVM based disks. One machine is using CentOS 6 Minimal as the Host OS, the other uses Ubuntu Server 11.04.

I moved the guest machine disks by using dd over ssh, while the guests were off.

I can move Ubuntu server guest machines between the two hosts and they work just fine on either. My Windows guest machine was created on the Ubuntu host and runs fine there, but gets the Blue Screen Error immediately on boot when I try to run it on the CentOS host.

The Error is tiled: IRQL_NOT_LESS_OR_EQUAL and reads:

STOP: 0x0000000A (0x00001016, 0x00000002, 0x00000000, 0x804F8FEC)

The Microsoft support information seems to indicate a hardware problem and suggests things like BIOS updates and removing computer components. Obviously that's not the problem here since the hardware is virtualized.

I tried moving the guest disk again to ensure that data wasn't damaged during the move, but it did not fix the problem.

Has anyone else encountered this problem when trying to move Windows guest machines between KVM hosts? Is there anything that can be done to allow Windows to move smoothly from one machine to another?

My understanding is that with virtualized hardware, the system sees the same hardware devices on any machine and therefor can use the same drivers since the real hardware is hidden from the OS. Are there exceptions to this where drivers could be an issue? And last, is there any way (besides a complete reinstall of Windows) to recover from this problem?

UPDATE:

XML Machine definition:

<domain type='kvm'>
  <name>xpvm2</name>
  <uuid>6ddec00b-9f00-29ad-5197-98264c24cabf</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='rhel6.2.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/mapper/mainvg-vm_xpvm2'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:f8:3a:21'/>
      <source bridge='br0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='vga' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
</domain>

UPDATE 2

ps -ef | grep qemu (broken into lines for readability)

CentOS Machine:

qemu      9742     1 99 Feb18 ?        22:51:48 /usr/libexec/qemu-kvm
-S -M rhel6.2.0 -enable-kvm
-m 1024
-smp 1,sockets=1,cores=1,threads=1
-name xpvm2
-uuid 6ddec00b-9f00-29ad-5197-98264c24cabf
-nodefconfig
-nodefaults
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/xpvm2.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control
-rtc base=localtime
-> -no-shutdown
-drive file=/dev/mapper/mainvg-vm_xpvm2,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-> -netdev tap,fd=28,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:f8:3a:21,bus=pci.0,addr=0x3
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-usb
-device usb-tablet,id=input0
-vnc 127.0.0.1:5
-vga std
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
-> root     23564  9518  0 17:38 pts/0    00:00:00 grep qemu

Ubuntu Machine:

    105       1616     1  7 17:46 ?        00:00:14 /usr/bin/kvm -S -M pc-0.14
-enable-kvm
-m 1024
-smp 1,sockets=1,cores=1,threads=1
-name xpvm2
-uuid 6ddec00b-9f00-29ad-5197-98264c24cabf
-nodefconfig
-nodefaults
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/xpvm2.monitor,server,nowait
-> -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-> -boot c
-drive file=/dev/mapper/mainvg-vm_xpvm2,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0
-> -netdev tap,fd=18,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:f8:3a:21,bus=pci.0,addr=0x3
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-usb
-device usb-tablet,id=input0
-> -vnc 127.0.0.1:0
-vga std
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
-> myname      1626  1493  0 17:49 pts/0    00:00:00 grep --color=auto qemu

UPDATE 3:

I have replaced the Ubuntu OS with CentOS on the original machine. Back on the original host but with CentOS now instead, the XP VM still does not boot. This leads me to believe that the problem is related to CentOS vs Ubuntu compatibility, and not compatibility of Host Hardware. Still no idea what to try.

That stop code, with the first parameter set to something relatively small (in this case, 0x1016) means that some code running in kernel mode, probably a device driver, tried to access virtual memory address 0x1016. This really only happens when that code uses a null pointer (which is invalid) and then adds some offset amount to that, in this case, 0x1016. This is almost certainly a device driver bug, brought about by moving the VM from one environment to one that is similar and related, but different.

I suggest that you move the VM back to its original environment and remove all the paravirtualized drivers. Then try moving it. If it works, re-apply the paravirtualized drivers from the new environment.