VMQ Offload Support Change After NIC Driver Update in Hyper-V Virtual Switch on Windows Server 2022

Answer

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.

Confirmed Facts

• VMQ is used by the Hyper‑V virtual switch only when the physical NIC reports VMqSupported=True and the adapter’s VMQ feature is enabled via Set‑NetAdapterVmq -Enabled $true.
• A NIC driver update can change the reported VMQ support (e.g., set VMqSupported=False in the INF), causing Get‑NetAdapterVmq to show Enabled=False and the virtual switch to fall back to software processing.
• Re‑enabling VMQ on the NIC (Set‑NetAdapterVmq -Name -Enabled $true) restores offload, provided the driver still supports the feature.

Likely Explanation

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.

Steps to Test and Mitigate

1. Check current VMQ state:

   Get-NetAdapterVmq -Name "" | Format-List Name, Enabled, VMqSupported

2. If VMQ is enabled and you suspect queue exhaustion, temporarily disable it:

   Set-NetAdapterVmq -Name "" -Enabled $false

3. Reset the virtual switch or disable/re‑enable the VM network adapters bound to it so the change takes effect:

   Get-VMNetworkAdapter -ManagementOS | Where-Object {$_.SwitchName -eq ""} | Disable-VMNetworkAdapter
   Start-Sleep -Seconds 2
   Get-VMNetworkAdapter -ManagementOS | Where-Object {$_.SwitchName -eq ""} | Enable-VMNetworkAdapter

4. Monitor for Connection Pool Exhaustion events (e.g., via PerfCounter \\TCPv4\\Connection Failures) and measure throughput with a representative workload (e.g., SMB file copy or iPerf).
5. If disabling VMQ removes the spikes but throughput drops excessively, try intermediate tuning: limit the number of VMQ queues (e.g., Set-NetAdapterVmq -Name "" -NumberOfQueuePairs 2) or adjust the VMQ weight (Set-NetAdapterVmq -Name "" -Weight 0) and repeat the test.

Verification

• After any change, run Get-NetAdapterVmq to confirm the requested Enabled and VMqSupported values.
• Check the virtual switch’s view: Get-VMNetworkAdapter -ManagementOS | Format-List Name, VMQEnabled – it should reflect the NIC’s setting.
• Observe offload counters with Get-NetAdapterStatistics (look for ReceivedBytes vs. ReceivedPackets trends) to see whether hardware processing is active.

Missing Diagnostic Detail

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.