Question
VMQ Offload Support Change After NIC Driver Update in Hyper-V Virtual Switch on Windows Server 2022
Neel Sage
0 reputation · 11 Nov 2023, 15:27 UTC
107.1K views
Loading…
0 reputation · 11 Nov 2023, 15:27 UTC
Goal: Determine whether disabling Virtual Machine Queue (VMQ) on a Hyper‑V virtual switch eliminates intermittent Connection Pool Exhaustion events under high network load, while quantifying any resulting throughput change for workloads that rely on hardware offload.
Constraints: The host runs Windows Server 2022 with Hyper‑V Integration Services matched to the OS build, and the NIC firmware must remain compatible with the driver version being evaluated. The impact of VMQ disabling on specific workloads (e.g., high‑throughput SMB or RDMA‑like traffic) is uncertain, and alternative per‑adapter VMQ tuning may be required to retain partial offload benefits.
Questions: Does disabling VMQ consistently prevent Connection Pool Exhaustion spikes during peak traffic? What is the expected throughput penalty for VMQ‑dependent workloads after VMQ is turned off? Are there intermediate VMQ settings (e.g., limiting queue count) that mitigate pool exhaustion without fully disabling the feature?
33275 reputation · 11 Nov 2023, 17:09 UTC
Disabling Virtual Machine Queue (VMQ) on the physical NIC will stop the Hyper‑V virtual switch from using VMQ offload, which eliminates the specific queue‑related Connection Pool Exhaustion spikes that have been observed when the NIC driver reports VMQ capability but the underlying queues become saturated. However, this comes with a throughput penalty for workloads that benefit from hardware offload (e.g., high‑throughput SMB or RDMA‑like traffic) because packet processing falls back to the host CPU. Intermediate VMQ tuning—such as reducing the number of queues or adjusting the VMQ weight—can often mitigate pool exhaustion while retaining some offload benefit.
hypervVMqSupported=True and the adapter’s VMQ feature is enabled via Set‑NetAdapterVmq -Enabled $true.VMqSupported=False in the INF), causing Get‑NetAdapterVmq to show Enabled=False and the virtual switch to fall back to software processing.Set‑NetAdapterVmq -Name -Enabled $true) restores offload, provided the driver still supports the feature.When VMQ is active, each virtual function (VF) or VM NIC is assigned a hardware receive queue. Under high burst traffic the finite number of queues can be exhausted, leading the switch to drop or queue packets in software, which manifests as Connection Pool Exhaustion events in the host’s networking stack. Disabling VMQ removes the queue limit, so all traffic is processed by the host’s TCP/IP stack, preventing the queue‑related exhaustion but increasing CPU utilization.
Get-NetAdapterVmq -Name "" | Format-List Name, Enabled, VMqSupportedSet-NetAdapterVmq -Name "" -Enabled $falseGet-VMNetworkAdapter -ManagementOS | Where-Object {$_.SwitchName -eq ""} | Disable-VMNetworkAdapter
Start-Sleep -Seconds 2
Get-VMNetworkAdapter -ManagementOS | Where-Object {$_.SwitchName -eq ""} | Enable-VMNetworkAdapterSet-NetAdapterVmq -Name "" -NumberOfQueuePairs 2) or adjust the VMQ weight (Set-NetAdapterVmq -Name "" -Weight 0) and repeat the test.Get-NetAdapterVmq to confirm the requested Enabled and VMqSupported values.Get-VMNetworkAdapter -ManagementOS | Format-List Name, VMQEnabled – it should reflect the NIC’s setting.Get-NetAdapterStatistics (look for ReceivedBytes vs. ReceivedPackets trends) to see whether hardware processing is active.To decide whether intermediate VMQ tuning is sufficient, we need to know the current number of VMQ queues reported by the NIC (NumberOfQueuePairs) under load. If this value is already low, further reduction may not help, and a full disable or driver rollback may be required.
Use comments to ask for clarification. Post a solution as an answer.
5,170 reputation · 11 Nov 2023, 20:56 UTC
On Windows Server 2022, disabling VMQ does not merely raise overall CPU usage—it collapses receive processing onto a single core (Core 0), which is often the real bottleneck during bursts. A middle path worth testing before a full disable is capping MaxQueues per virtual NIC rather than removing VMQ entirely. This keeps hardware queues active but limits how many the switch will assign, reducing pool pressure while preserving some multi-core distribution. You can also steer placement with BaseProcessorGroup to avoid concentrating interrupts on the same logical processors as host management traffic. Because NIC driver updates can reset custom VMQ mappings to defaults, re-run Get-NetAdapterVmq and verify queue assignments after any firmware or driver change before concluding the offload path is unstable.