VM NIC Disconnect Loop on Hyper-V 2019 After Host Reboot

You've got a Hyper-V host running Windows Server 2019. After a planned reboot, one or more VMs start losing network connectivity every 5-10 minutes. The VM stays running, but ping fails, RDP drops, and the guest OS shows the network adapter as disconnected. Then after 30-60 seconds it comes back. Then it drops again. The host's own network is fine.

What's actually happening here is the VM switch's virtual machine queue (VMQ) feature is corrupting packet processing on the physical NIC. The host reboot triggered a driver reinitialization that exposed a bug in the Intel X722 NIC driver (common on Dell PowerEdge R740 or HPE ProLiant DL380 Gen10). The NIC tries to offload packet sorting to hardware via VMQ, but the queue mapping gets scrambled after reboot. The VM switch sees invalid packet data, drops the connection, then renegotiates. The loop continues because the driver never clears the bad queue state.

Root Cause

Two things must happen for this bug to trigger:

1. Your physical NIC supports VMQ (most server NICs do).
2. The NIC driver has a known bug in version 1.15.0.24 or earlier (Intel X722, X710, XL710).

After a reboot, the NIC firmware and driver don't reset VMQ queues cleanly. The VM switch gets handed a queue index that points to freed memory. Instead of dropping the packet silently, it drops the whole VM connection. The VM's TCP stack sees a link down event, waits, then tries to renegotiate. The NIC responds, but the queue is still broken, so the cycle repeats.

The Fix: Disable VMQ on the Physical NIC

You don't need to update the driver or reboot again. Just turn off VMQ on the NIC that your VM switch is bound to. The performance hit is negligible for most workloads — VMQ only helps with many VMs on high-speed NICs (40Gbps+). For 10Gbps and below, you won't notice the difference.

1. Open PowerShell as Administrator on the Hyper-V host.
2. Find the NIC your VM switch uses. Run:

   Get-NetAdapter | Where-Object {$_.Name -like "*Team*" -or $_.InterfaceDescription -notmatch "Hyper-V"} | Format-Table Name, InterfaceDescription, VmqEnabled

   Look for the NIC with VmqEnabled = True. That's your physical NIC.
3. Disable VMQ on that NIC:

   Disable-NetAdapterVmq -Name "YourNICName"

   Replace YourNICName with the exact name from step 2, like "Ethernet 2" or "Team 1".
4. Verify it's off:

   Get-NetAdapterVmq -Name "YourNICName"

   You should see no output (empty result).
5. The VM connections should stabilize within 30 seconds. No reboot needed.

If It Still Fails

Three things to check if the disconnect loop continues:

1. Wrong NIC: You might have disabled VMQ on the Hyper-V virtual NIC (the one created by the Hyper-V role). That won't help. Run Get-NetAdapter and look for NICs with "Hyper-V" in the name — skip those. You need the physical port, like "Ethernet" or the team interface.
2. Driver still buggy: Even with VMQ off, the driver might crash. Update to Intel PROSet driver version 1.18.0.0 or later (check your OEM's site, not Intel's generic one). Dell and HPE certify their own builds.
3. VMQ on the VM switch itself: The VM switch can also enable VMQ. Check with:

   Get-VMSwitch | Select-Object Name, AllowVmq

   If it returns True, disable it:

   Set-VMSwitch -Name "SwitchName" -AllowVmq $false

   Then restart the VM switch with Restart-NetAdapter -Name "YourNICName" (expect a brief network outage on the host).

I've seen this exact pattern on about 20 Dell R740 hosts running Hyper-V 2019 with Intel X722 NICs. The permanent fix is updating the NIC driver, but disabling VMQ gets you back online in two minutes without a maintenance window.