VM Network Interface Keeps Disconnecting in Hyper-V

Server & Cloud Intermediate 👁 19 views 📅 Jun 16, 2026

Your Hyper-V VM loses network every 30-60 seconds, then reconnects. It's usually a power management setting or a driver mismatch. Here's the fix.

You're running a Hyper-V VM—Windows Server 2019, 2022, or even a Linux guest—and out of nowhere the network drops. Not permanently, but in a loop: the NIC goes offline for 10-20 seconds, then comes back. You see the red X or the yellow warning triangle in the taskbar. Event Viewer might show something like "The network adapter has been disconnected" or an endless stream of "Link state changed" events. This usually happens under load—say during a backup job, a large file copy, or a database query that pushes traffic. I've seen it most on Dell PowerEdge and HP ProLiant hosts with Broadcom or Intel NICs.

The root cause is almost always one of three things, and I'll order them by how often I see them: 1) Power saving on the VM's virtual NIC, 2) Outdated or mismatched Hyper-V Integration Services, or 3) Virtual Machine Queue (VMQ) misconfiguration. Less commonly, it's a bad physical switch port or a flaky cable, but let's rule out the software first.

Step 1: Turn Off Power Saving on the VM's Virtual NIC

Windows loves to save power, and it's terrible at deciding when to do it. This is my #1 suspect. On the host machine—not inside the VM—open Hyper-V Manager. Do this:

  1. Right-click the VM that's having problems and select Settings.
  2. In the left pane, under Hardware, find the Network Adapter (not the management OS adapter, the one assigned to this VM).
  3. Wait—this is where people get confused. Do not click the plus sign to expand it. Click the network adapter line to select it.
  4. Look in the right pane for a button or link labeled Advanced Features. Click it.
  5. Scroll down to the bottom of Advanced Features. You'll see a checkbox: Enable SR-IOV. That's not what you want.
  6. Actually, the power saving is not directly in Hyper-V Manager. You need to go to the host's physical NIC settings. Open Device Manager on the Hyper-V host (not the VM).
  7. Expand Network adapters, find the physical NIC that the VM is using (usually the one you've assigned to a virtual switch).
  8. Right-click that physical NIC and choose Properties.
  9. Go to the Power Management tab.
  10. Uncheck "Allow the computer to turn off this device to save power."
  11. Click OK.
  12. Also, inside the VM, go to Device Manager (in the VM), find the Microsoft Hyper-V Network Adapter, right-click it, Properties, Power Management, uncheck the same box.

After doing this, restart the VM. Test it. If the disconnect loop stops, you're done. If not, move to Step 2.

Step 2: Update Hyper-V Integration Services Inside the VM

I've fixed dozens of these loops by updating Integration Services. The symptom is that the VM's network driver and the host's driver don't agree. This happens most often when you've migrated a VM from an older host (like 2012 R2) to a newer one (2019 or 2022). Here's how:

  1. In Hyper-V Manager, right-click the VM and choose Shut Down (not Turn Off—you want a clean shutdown).
  2. Start the VM back up.
  3. While the VM is running, go to the VM's Action menu (or right-click the VM) and select Insert Integration Services Setup Disk.
  4. This mounts a virtual CD in the VM. Inside the VM, open File Explorer, go to the CD drive (usually D:), and run setup.exe.
  5. Follow the wizard. It will update the Hyper-V-specific drivers and services. This takes about 2 minutes.
  6. Restart the VM when prompted.

If the VM is a Linux guest, you don't need this step—Linux uses built-in kernel drivers. For Linux, skip to Step 3.

Test again. If the disconnect is gone, great. If not, proceed.

Step 3: Disable Virtual Machine Queue (VMQ) on the VM

VMQ is a feature that offloads packet sorting to the physical NIC hardware. It sounds good, but it's buggy with some NICs and switch firmware. In fact, Microsoft recommends disabling VMQ for high-traffic VMs in certain scenarios. The disconnect loop is one of those scenarios. Here's how to do it:

  1. On the Hyper-V host, open PowerShell as Administrator.
  2. Run this command to see the current VMQ settings for all VMs:
    Get-VMNetworkAdapter -VMName * | Select VMName, VMQ

    You'll see a list of VMs and whether VMQ is enabled (True) or disabled (False).

  3. To disable VMQ for the problematic VM, replace VMName with the actual name of your VM (in quotes if it has spaces):
    Set-VMNetworkAdapter -VMName "YourVMName" -VmqWeight 0

    The -VmqWeight 0 flag disables VMQ for that adapter.

  4. If you have multiple network adapters on that VM, you need to specify which one. Use Get-VMNetworkAdapter -VMName "YourVMName" first to see the adapter names, then:
    Set-VMNetworkAdapter -VMName "YourVMName" -Name "Network Adapter" -VmqWeight 0
  5. Restart the VM. (Yes, you have to restart it.)

Test again. In my experience, this fixes about 80% of the remaining cases.

What to Check If It Still Fails

If you're still stuck, start looking outside the server. Try these:

  • Check the physical switch port. Log into your managed switch, look at the port the host is connected to, and see if it's flapping (going up/down). If it is, try a different port or a different cable.
  • Update the host's physical NIC driver and firmware. Go to the manufacturer's site (Broadcom, Intel, Mellanox) and get the latest driver. A driver from 2020 can cause this.
  • Disable RSS (Receive Side Scaling) on the host NIC. In the physical NIC's Advanced settings in Device Manager, find "RSS" and set it to Disabled. Then restart the host.
  • If the VM is a domain controller, check for DNS loop issues. A DC that can't resolve its own name will sometimes drop the NIC because of service dependencies. Fix DNS first.
  • Last resort, create a new virtual switch on a different physical NIC (if you have one), attach the VM to that new switch, and test. This isolates whether the problem is the switch or the NIC hardware.

That's the full playbook. Start with the power saving—it's free, quick, and fixes half the cases. If that doesn't work, update the Integration Services. Then kill VMQ. If it still loops, you're probably dealing with a hardware or driver issue on the host side. Don't waste time inside the VM beyond those steps; the host is where the problem lives.

Was this solution helpful?