WinXP + virtio + proxmox 1.9 -> crash

[linum]

Hello,

I think there is a problem that is related to Windows XP (current SP3 with current updates till 2011-10-19) using virtio using the latest drivers from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ and a currrent proxmox 1.9. Using a virtio nic results in a BSOD or a message (sorry german) like this:

Der Computer ist nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x1000000a (0x00bc000b, 0x00000002, 0x00000000, 0x804fdaa4). Ein volles Abbild wurde gespeichert in: C:\WINDOWS\Minidump\Mini101911-01.dmp.

Removing the virtio nic and using a realtek 8139 nic seems to solve the problem. Running various linux VM or even Windows Server 2008 seems to trigger the bug. I know that the error message above is normally related to some kind of hardware trouble but the same host runs the same Windows XP VM more than 100 days without a problem (with proxmox 1.7 and an older release of virtio drivers). Even a fresh installation of Windows XP using virtio drivers triggers the bug. To be sure that this problem is not related to any kind of hardware failling in the host system one host systems is running memtest+ for 24h now without a problem. So I think everything needed to reproduce the bug should be:

1) Install current proxmox 1.9 on a host (I used Intel Xeon cpus)
2) Install Windows XP with SP3 and install all current updates.
3) Remove the nic and install the virtio nic with the drivers from the fedora project (link is above)
4) Enable RDP on the Win XP system and just surf the web or let the system alone for some time.

It should not take more than an hour to trigger a bsod or the error from the message above.

A similar problem was reported some time ago at http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2998292&group_id=180599. But I can't find this bug in lauchpad so far.

Just to make sure, here is pveversion output
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-47
pve-kernel-2.6.32-6-pve: 2.6.32-47
qemu-server: 1.1-32
pve-firmware: 1.0-14
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.29-2pve1
vzdump: 1.2-16
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6

name: winxp
ide2: none,media=cdrom
ostype: wxp
ide0: local:134/vm-134-disk-1.raw
memory: 512
sockets: 1
boot: ca
freeze: 0
cpuunits: 1000
acpi: 1
kvm: 1
bootdisk: ide0
onboot: 0
cores: 1
vlan94: rtl8139=F2:E0:3D:E4:87:60

Just a note, the config is the currently running VM with a rtl8139 emulation. The only difference to a not working VM is the "virtio vs rtl8139" keyword. And even the vlan makes no difference, this is just the machine we're I need to use vlan. The same problem is triggered on a different machine with vlan (that is currently running the memtest86+ mentioned above).

 

[tom]

post also the output of 'pveversion -v' and the config file from your VM (cat /etc/qemu-server/VMID.conf).

 

[linum]

Is there anyone else besides fortechitsolutions with virtio trouble? It would be nice if someone could at least confirm "no trouble here with winxp sp3 + latest virtio + proxmox 1.9". I don't know what to try next ...

 

[oxiwan]

I had the same problem with two proxmox servers.

With 1.7 version, no problem to running five VM XP with VIRTIO nic. (driver provided by virtio-win-1.1.16.iso )

After upgrading to 1.9, several BSOD with the same message:
0x1000000a (0x00bc000b, 0x00000002, 0x00000000, 0x804fdaa4)

I tested latest driver provided by virtio-win-0.1-15.iso, but it did not solved.

To solve the problem, I disabled virtio nic and add realtek 8139 nic.

pveversion -v
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.35-2-pve
proxmox-ve-2.6.35: 1.8-13
pve-kernel-2.6.32-3-pve: 2.6.32-13
pve-kernel-2.6.35-2-pve: 2.6.35-13
qemu-server: 1.1-32
pve-firmware: 1.0-13
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.28-1pve5
vzdump: 1.2-15
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6

 

[linum]

I'm glad to hear that I'm not the only one. As you described my solution was to disable virtio and use a realtek 8139 nic too.

I don't think that proxmox is the real source behind these problems but proxmox uses the latest available kvm+qemu. And I think there's a regression that causes this kind of problems. Searching the net for similar bug reports I didn't find other people besides some older posts with older qemu+kvm versions.

Maybe we should create a bug report against stock qemu+kvm+virtio but I'm not sure to which subsystem we should file the report. Maybe virtio drivers for windows are the most suitable subsystem, since linux seems to run fine with the current versions.

And again, thanks for reporting the issue.

 

[marotori]

I'm glad to hear that I'm not the only one. As you described my solution was to disable virtio and use a realtek 8139 nic too.

I don't think that proxmox is the real source behind these problems but proxmox uses the latest available kvm+qemu. And I think there's a regression that causes this kind of problems. Searching the net for similar bug reports I didn't find other people besides some older posts with older qemu+kvm versions.

Maybe we should create a bug report against stock qemu+kvm+virtio but I'm not sure to which subsystem we should file the report. Maybe virtio drivers for windows are the most suitable subsystem, since linux seems to run fine with the current versions.

And again, thanks for reporting the issue.

I have the same issue with Windows 2003 guests.

Odd things I have noted are:

- machines do not boot with virtio. Had to change to IDE
- network does not work with virtio drivers

No amount of upgrading the drivers for virtio workls - nothing!

So.. here is an odd one.

I rebuilt a machine on proxmox 1.9 with a fresh install of win2003. Same virtio drivers etc.

Amazing! It all works!!

I suspect there is some kind of issue with how the hardware is being addressed

Rob

 

[linum]

I suspect there is some kind of issue with how the hardware is being addressed

As fas as I know there should be no difference. Hmm, or wait. Maybe there's a new/changed configuration option with newly created VM? Here's my configuration for an old VM that crashed frequently.

name: winxpsp3
vlan1: virtio=52:54:00:xx:xx:xx
ostype: wxp
memory: 512
onboot: 0
sockets: 1
cores: 1
boot: c
freeze: 0
cpuunits: 1000
acpi: 1
kvm: 1
bootdisk: virtio0
ide0: local:104/104.raw

And I already reinstalled a fresh version of Windows XP SP3 with virtio drivers and the trouble remains the same. So there must be something else or a combination of some "unrelated" items that causes this kind of problems.

 

[hk@]

just my 2 cents - virtio has been discussed (especially on network drivers) several times.
the basically always working solution is to go for intel e1000 networking instead of virtio for the VMs.
virtio networking typically breaks in high-load environments, eg. pinging all day works fine, but transferring some big data chunks makes the network go away / break.
Therefore if you want to deliver a clean VM without trouble for any user with eg. windows rdp admin level - you got to leave virtio behind and go for some more stable ways that won't break when upgrading the host kernel or where you have to update drivers within the VM on a regular basis to keep it working.