Troubleshooting Hyper-V VM Network Connectivity: Ping Failure Between Host and Guest Systems


3 views

When dealing with Hyper-V networking issues, the first thing I typically check is whether the virtual switch configuration matches the expected behavior. In this case, we have:

Network Topology:
- Physical Router: 192.168.1.254/24
- Host OS (Windows Server/Hyper-V): 192.168.1.10/24
- Guest VM: 192.168.168.1.110/24 (misconfigured)

The immediate red flag is the VM's IP address (192.168.168.x) being in a different subnet than both the host (192.168.1.x) and router. Despite the identical subnet mask (255.255.255.0) and gateway (192.168.1.254) configuration, this creates a fundamental routing problem.

Run this PowerShell command to check your virtual switch setup:

Get-VMSwitch | Format-Table Name, SwitchType, NetAdapterInterfaceDescription

For your external switch bound to the physical NIC, ensure it shows:

Name       SwitchType NetAdapterInterfaceDescription
----       ---------- -----------------------------
External   External   Intel(R) Ethernet Connection (2) I219-V

The VM should be in the same 192.168.1.0/24 subnet as your host and router. Change the VM's IP configuration:

# Using PowerShell in the VM:
New-NetIPAddress -IPAddress 192.168.1.110 -PrefixLength 24 -DefaultGateway 192.168.1.254 -InterfaceIndex (Get-NetAdapter).ifIndex
Set-DnsClientServerAddress -InterfaceIndex (Get-NetAdapter).ifIndex -ServerAddresses 8.8.8.8

If the issue persists after correcting the IP, try these diagnostic commands:

# On Host:
Test-NetConnection -ComputerName 192.168.1.110 -Port 445
Get-NetAdapter | Where Status -ne "Up" | Restart-NetAdapter

# On VM:
Test-NetConnection -ComputerName 192.168.1.10 -TraceRoute
Get-NetRoute | Where DestinationPrefix -eq "0.0.0.0/0"

Sometimes the virtual switch cache gets corrupted. Reset it with:

# Remove and recreate the virtual switch
$vswitch = Get-VMSwitch -Name "External"
Remove-VMSwitch -Name $vswitch.Name -Force
New-VMSwitch -Name $vswitch.Name -NetAdapterName (Get-NetAdapter -Physical).Name -AllowManagementOS $true

For persistent issues, capture packets on both host and VM:

# On Host:
New-NetEventSession -Name HyperV_Diag -LocalFilePath C:\temp\HostCapture.etl
Add-NetEventPacketCaptureProvider -SessionName HyperV_Diag -Level Verbose
Start-NetEventSession -Name HyperV_Diag

# On VM (using built-in pktmon):
pktmon start --etw -m real-time -c -p 0
ping 192.168.1.10
pktmon stop

Remember to check the Hyper-V Virtual Switch Manager in the GUI to verify the external switch binding matches your physical NIC, especially after Windows Updates that might reset network configurations.


Today I hit a frustrating network snag in my Hyper-V environment where my host machine (192.168.1.10) suddenly couldn't communicate with my VM (192.168.1.110), despite both being configured with the same gateway (192.168.1.254) and subnet mask (255.255.255.0). The external virtual switch configuration appeared correct, yet bidirectional ping attempts failed.

First, I verified basic network connectivity:

# From Host:
ping 192.168.1.254  # Success
ping 192.168.1.110  # Fail

# From VM:
ping 192.168.1.254  # Success
ping 192.168.1.10   # Fail

The external virtual switch showed these properties in PowerShell:

Get-VMSwitch -Name "External Switch" | Format-List

Surprisingly, I discovered the switch had somehow lost its physical NIC binding. This explained why VMs could communicate with each other but not with external resources.

To re-establish proper binding, I executed:

Remove-VMSwitch -Name "External Switch" -Force
New-VMSwitch -Name "External Switch" -NetAdapterName "Ethernet" -AllowManagementOS $true

This PowerShell sequence completely rebuilt the virtual switch with proper NIC binding. After this, I verified the network connectivity:

Test-NetConnection -ComputerName 192.168.1.110 -Port 3389

For comprehensive network analysis, I used these diagnostic commands:

# Check ARP tables
arp -a

# Verify routes
route print

# Test firewall rules (even though disabled)
Get-NetFirewallRule | Where-Object { $_.Enabled -eq 'True' }

Interestingly, the ARP cache showed incomplete entries, suggesting layer 2 communication issues between the host and VM.

To avoid recurrence, I implemented these safeguards:

# Create switch backup
Export-VMSwitch -Name "External Switch" -Path "C:\switch_config.xml"

# Set NIC power management
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Energy Efficient Ethernet" -DisplayValue "Disabled"