Guest: Windows 2008 R2 slow & high system interrupt count

kofik

Active Member
Aug 5, 2011
62
10
28
G'day

We have several proxmoxes at work, most of the VMs are running a sort of Linux where I don't see any negative performance. Now I recently set up a W2k8 R2 VM giving it a virtio Network and virtio block device. I installed the for both kind of hardware the latest drviers than are inside rhe RH-provieded 1.2.0-1 package for RHEL6.1.

The Machine boots very fast, but when I install updates or do any sort of higher load
- Proxmox shows almost no cpu usage by this VM
- Windows Taskmamanger says high load (80% on let's say 2 vCPUs, but most is idle?)
- Only the resource monitor reveals a high count of system interrupts which seems to bugger the Windows VM dramatically

Is this a 'known issue' caused by Windows or the virtio-win drivers? I'd be interested to know why this is actually happening - and if possible resolve this 'problem' (well, this machine cannot be 'fixed' by switching to Linux) ;)
 
Even worse I could confirm that by doing heavy network stuff (big file transfer) after a period of high system interrupt count the network card loses connectivity and dmesg on the host systems also spits something out about some tun/tap interfaces. The only way to recover the network connectivity seems to reboot the VM and off we go.

Interesting I'll check back with these drviers - but essentially I thought 1.1.6 (via Fedora) are the same drivers but 1.2.0 was just the RH-provided one that were signed.
 
G'day

Thanks I think I can give it a try this weekend. Plus someone mentioned in this thread there may be newer drivers from Fedora that might fix some related bugs too. I'll report when I have more results
 
Sorry for the delay I could only update to 2.6.32-6-pve Kernel and according QUEMU from pvetest today. Expecting results tomorrow. But I suspect the Windows drivers to be the source of the problem (those from RHEL 6.1). If I fail again I will try those from Fedora
 
Sorry for the delay I could only update to 2.6.32-6-pve Kernel and according QUEMU from pvetest today. Expecting results tomorrow. But I suspect the Windows drivers to be the source of the problem (those from RHEL 6.1). If I fail again I will try those from Fedora
Hi,
perhaps you can try also with e1000-driver and ide?! I choose this combination on windows because of less trouble (windows don't want to be reactivated after kvm-update so often and network work's stable).

Udo
 
OK, here are some first results, after the update still using RHEL's 1.2.0-1 driver package, doing a robocopy on the VM trying to shuffle some data from a physical 2003 R2 server (around 700MB of random files)

* VM still gets unresponsive
* High count interrupt (up 41% of CPU time), only around 10% was for robocopy.
* robocopy stated it to 2' 24'' to copy a mere 770MB, resulting in a transfer rate of about 5MB/s
* After robocopy has finished the responsiveness of the VM's UI comes back to normal

~$ pveversion -v
pve-manager: 1.8-23 (pve-manager/1.8/6533)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.8-42
pve-kernel-2.6.32-6-pve: 2.6.32-42
qemu-server: 1.1-31
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

I'll give the fedora drivers a try and edit this post once I have the results. e1000 would be the last option since 'normall' the virtio drivers 'should' have lower CPU load than the emulated device and the IO should also be better to with virtio disks (and windows drivers).
 
OK, here are some first results, after the update still using RHEL's 1.2.0-1 driver package, doing a robocopy on the VM trying to shuffle some data from a physical 2003 R2 server (around 700MB of random files)

Test 1: PVETestKernel 2.6.32-pve-6 + RHEL virtio-win 1.2.0-1
* VM still gets unresponsive
* High count interrupt (up 41% of CPU time), only around 10% was for robocopy.
* robocopy stated it to 2' 24'' to copy a 770MB, but I really believe it was wrong because even a single 7MB JPEG file could take up to 15'' to copy (?!)
* After robocopy has finished the responsiveness of the VM's UI comes back to normal

~$ pveversion -v
pve-manager: 1.8-23 (pve-manager/1.8/6533)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.8-42
pve-kernel-2.6.32-6-pve: 2.6.32-42
qemu-server: 1.1-31
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

Test 2: PVETest Kernel 2.6.32-pve-6+ Fedora Virtio-win with date stamp 08-2011:
RHEL Storage driver announced itsel as 60.x, fedora as 61.x. At first sight I believed everything was better then after some minutes I observed robocopy to take 10-15 seconds for a 7MB JPEG file, 30-40% CPU time used for intterrupt :-(
OK: No change, no improvement.

Test 3: Going back to e1000 and IDE?
Positive: UI stayed responsive, seems to be a problem with virtio drivers :-/
Negative: Still feels slow (agreed robocopy isn't a good benchmark).
The cpu time passed for interrupts still is higher than any other process and sometimes the copying is also waiting for data (no idea) but hte interrupt time is around 10% which I feel is acceptable compared to virtio-win.
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!