Bad Windows network performance - how to improve?

C

CPO_Siemens

New Member
Proxmox Subscriber
Aug 4, 2026
20
2
3
We migrated some Windows 11 VMs from vSphere to Proxmox and are experiencing network bottlenecks.
I compared two similar VMs (one on vSphere with vmxnet3, one on Proxmox with virtio) and did some iperf3 runs which showed, that the vSphere NIC saturates the 10G connection that the host has to the test server while the Proxmox VM barely reaches 6G outbound and max. 2G inbound while the VM-bridge is attached to a 2x100G bond (which as it's own problems but does way more than 6G).

I also tried enabling multiqueue (set to 8 to match the 8 cores of the VM) and compared different virtual NICs (vmxnet3 was way worse than virtio on Proxmox, e1000 slightly worse as well).
Virtio-Win drivers are also up to date (0.1.302 as of writing this, first used 0.1.285 - no difference).

Any ideas?
 
Didn't know that - tested it.
For outwards traffic this made a tremendous difference. Outbound with 4 threads about 22-30G, inbound with 4-6 threads about 3-6G.
The higher numbers are with multiqueue enabled (set to 4, if I actually use the same number as vCores the VM becomes more or less unresponsive during the transfer).
That is a lot better - especially outbound for some reason.
Up to 6G is also still less than with single threaded iperf3 on vSphere though. Is there any way to meaningfully improve the singlethreaded performance as well?
Not all SMB connections are multi threaded (I think they're single threaded by default) and SMB is our main use case here.
 
Last edited:
vSphere VMs are on Xeon 6242Rs, Proxmox on Xeon 6354s so slightly newer gen on Proxmox (according to Passmark both should have similar single threaded performance with the Proxmox's CPU slightly better on multithreaded tasks).
 
Sorry, I honestly don't quite understand what you mean by your first sentence.
I can say however, that the Proxmox hosts don't have any other cpu performance problems. Other CPU-intensive tasks that we tested on both systems were comparable or even faster on the Proxmox cluster.
 
I can't exactly reproduce the load of the host systems while I ran the previous tests but I am sure the vSphere host was only lightly loaded by now (only a few VMs are left running there, most are on Proxmox by now). I can see in my monitoring history however that the Proxmox host had something between 10% and 20% CPU usage while I ran the tests with no large additional network load (the network usage from these times correlates roughly with the numbers measured with iperf on the guest).

However I ran some tests. We have three kinds of hosts in the Cluster: the abovementioned Intel nodes (2x Xeon 6354, only compute, no storage), Newer HCI Nodes (1x EPYC 9175F, we only use them for Ceph, they normally have no VMs running on them), Older HCI nodes (2x EPYC 75F3, compute + storage).

I just created 3 completely fresh Windows VMs (Win 10 22H2, Win 11 23H2, Win 11 25H2 - to test whether there are noticable differences between Windows versions) on 3 separate new-HCI nodes so they were completely "alone" on the host. All with the same hardware specs (4 vCPUs, 8G RAM, same NIC on same VLAN...).

On the new-HCI nodes, without other VMs, all three VMs got about 12-14Gb of single threaded performance in both directions throughout multiple iperf runs (all one after another to the same target).

On the old-HCI nodes the number began to fluctuate much more - especially for inbound traffic. Upload was still mostly 10-20G, averaging roughly 13-15G while download dropped much more to fluctuating 5-10G, mostly averaging about 7-8G.

All numbers so far were similar between the three VMs and the old-HCI nodes which have 20-40% CPU load and 40-70% RAM usage.

I then moved the VMs to lightly loaded Intel nodes and the number stayed very similar, with only one drop of a VM's download to 3G inbound which I then couldn't reproduce.

Last thing I checked: I moved all 3 test VMs to the same node which at that time had the highest load in the cluster (with the test VMs about 30% CPU usage + ~20% RAM). Outbound still averaging 13-15G, inbound got all over the place though. Sometimes dropped to 2G, sometimes going up to 12G with large fluctuations during the runs.

It seems to me that the NIC performance under Windows is just not stable at all and begins to intermittently suffer greatly as soon as the host is even slightly loaded.

Edit: while reviewing the tests I noticed that the numbers seem to fluctuate most on the 23H2 VM... no idea if this is significat though.
 
Last edited:
Your latest tests actually suggest that VirtIO itself is not the main bottleneck.

The important result is that the same Windows VM reaches ~12–14 Gbit/s single stream in both directions on an otherwise idle EPYC 9175F host. Once the host gets busier, mainly RX performance becomes unstable while TX stays relatively consistent.

That points more towards scheduling / vhost / RSS / IRQ / NUMA locality than a general NetKVM limitation. The fact that queues=8 can even make the VM almost unresponsive is another indication that simply matching the number of queues to the number of vCPUs is not necessarily optimal.

I would try three things next:

- Test queues=1/2/4/8 and monitor per-vCPU/DPC load in Windows.

- Run the same tests with a Linux VirtIO VM. If Linux RX also drops under host load, Windows/NetKVM is probably not the culprit.

- On the dual-socket hosts, check NUMA placement of the VM, vhost threads and NIC IRQs. The only single-socket host in your tests is also the one giving consistently good results, which is quite interesting.

Also, the original VMware comparison is somewhat inconclusive: the VMware host was limited by a 10G uplink, while Proxmox already achieves 12–14 Gbit/s single-stream on an idle host. So we don’t actually know how fast the VMware VM could have gone without that 10G bottleneck.
 
You must log in or register to reply here.
Top Bottom
Back