Fix VM Network Disconnect Loop on Hyper-V 2022

Server & Cloud Intermediate 👁 6 views 📅 Jun 21, 2026

Your VM keeps losing network every few minutes? It's a known power-saving bug in Hyper-V. This fix stops the disconnect loop in its tracks.

Quick answer

Disable VMQ on the host's physical NIC. Run this in PowerShell: Disable-NetAdapterVmq -Name "YourNICName". Then restart the VM. Done.

Why this happens

I know this error is infuriating. You're working on a VM, and suddenly the network drops. Then it comes back. Then drops again. Sometimes every 30 seconds. This tripped me up the first time too when I ran a help desk blog back in 2018.

This loop happens because of a bug in Hyper-V's virtual switch when VMQ (Virtual Machine Queue) is enabled on the host's physical NIC. VMQ is a feature that offloads packet processing to the NIC hardware. Sounds good in theory. But on many NICs, especially Realtek and some Intel models, VMQ causes the virtual switch to reset the VM's network connection when the host's NIC changes speed or handles high traffic. You'll see it most when you're doing heavy file transfers or running database queries from the VM.

Here's the real trigger: when the host NIC negotiates link speed (like 1 Gbps), VMQ queues get mismapped, and the Hyper-V virtual switch drops the VM connection. The VM reconnects, then it happens again. Loop.

Fix steps

  1. Check which NIC your VM uses. Open Hyper-V Manager, right-click your VM, go to Settings > Network Adapter. Note the virtual switch name (usually "Default Switch" or something custom).
  2. Find the physical NIC behind that switch. Open PowerShell as admin: Get-VMSwitch | Format-List Name, NetAdapterInterfaceDescription. Look for the switch name from step 1. The NetAdapterInterfaceDescription tells you which physical NIC it uses.
  3. Disable VMQ on that NIC. In the same PowerShell window, run: Disable-NetAdapterVmq -Name (Get-NetAdapter | Where-Object { $_.InterfaceDescription -eq "[your NIC description from step 2]" }).Name. Or just do: Get-NetAdapter | Disable-NetAdapterVmq to disable on all NICs (safe on servers with one NIC).
  4. Restart the VM. Not just the guest OS — do a full shutdown/start from Hyper-V Manager. Restarting from inside the guest often doesn't clear the VMQ mapping.
  5. Test. Ping an external IP (like 8.8.8.8) from the VM. Watch for drops. In my experience, the loop stops immediately.

Alternative fixes

If disabling VMQ doesn't work (rare, but happens with some Broadcom NICs), try these:

Fix 2: Disable IPv6 offload

Open the host's NIC properties (Control Panel > Network and Sharing Center > Change adapter settings > right-click NIC > Properties > Configure > Advanced tab). Find "IPv6 Checksum Offload" and set to Disabled. Also disable "Large Send Offload" and "TCP Checksum Offload". These offloads can also cause VM disconnect loops.

Fix 3: Use a dedicated virtual switch with static MAC

In Hyper-V Manager, create a new virtual switch (external type). Then edit the VM's settings, set the MAC address to Static, and use a unique address (like 00-15-5D-01-02-03). This prevents MAC address conflicts that sometimes trigger disconnects.

Prevention tip

On new Hyper-V hosts, disable VMQ on all physical NICs right after installing Windows Server. Then create your virtual switches. You'll never see this loop. Also, avoid using the "Default Switch" that Hyper-V creates automatically — it's fine for testing, but in production, always create your own external switch. That little piece of advice saved me hours of ticket time when I was managing 200+ VMs.

If you have multiple NICs, team them with SET (Switch Embedded Teaming) instead of using VMQ. SET doesn't have this bug. But that's a whole other article.

Was this solution helpful?