As shown in the above output, VM1 is assigned with the correct VSID (5001) which is absolutely fine. In case output returns a wrong VSID for VM1, use Set-VMNetworkAdapter command to assign the correct VSID to VM1.
Execute the same command on HVHOSTB to make sure VM3 is assigned with the same VSID (5001). The output should return similar to below on HVHOSTB:
- Lookup Records are incorrect for VM1 and VM3
Lookup Record is what WNV module uses to reach out to virtual machines located on the local or remote Hyper-V Servers. Lookup records are created using Set-NetVirtualizationLookupRecord PowerShell cmdlet. Each lookup record is created with a Provider Address which tells each Hyper-V Host where to send the traffic for each virtual machine participating in the Hyper-V network virtualization. A lookup record looks like below:
VMName VM1 -CustomerAddress “10.0.0.99” -ProviderAddress “192.168.10.67” -VirtualSubnetID “5001” -MACAddress “00155D013202” -Rule “TranslationMethodEncap”
The lookup records are created for every virtual machine participating in the Hyper-V network virtualization and must be populated on all Hyper-V hosts hosting the customer virtual machines.
To check the Lookup records on HVHOSTA and HVHOSTB, execute the below command on both the Hyper-V Hosts:
- Get-NetVirtualizationLookupRecord | FT VMName,MACAddress,VirtualSubnetID,CustomerAddress,ProviderAddress –AutoSize
The command should return the below output on both the Hyper-V hosts:
Since we are troubleshooting communication issues between VM1 and VM3, make sure to check the following items for VM1 and VM3 in the above output on both the Hyper-V hosts.
- MAC Addresses for both the virtual machines are correct. MAC Addresses can be assigned either statically or dynamically. Give a very close look at this part to ensure MAC Addresses are correct for both the virtual machines. Since SCVMM ensures that each virtual machine is assigned with a unique MAC Address, there is no need to pay attention here if HNV configuration is deployed via SCVMM.
- VirtualSubnetIDs assigned to VM1 and VM3 are correct. VM1 and VM3 must be assigned with VSID 5001 which is correct as per the output shown above.
It is imperative to understand that Lookup Records are also created with the correct VSID of the virtual machine which is completely different from assigning a VSID to a virtual machine.
- Provider Addresses assigned to VM1 and VM3 are correct. For VM1, PA should be 192.168.10.67 and for VM3, PA should be 192.168.10.68. As per the output above, VM1 and VM3 are assigned to correct provider addresses.
In case you see any issues with the above output, re-populate lookup records on both the Hyper-V hosts using Set-NetVirtualizationLookupRecord PowerShell cmdlet.
The first part of this article series highlighted two approaches you can follow to troubleshoot issues with Hyper-V Network Virtualization. The first approach is to verify the Hyper-V network virtualization configuration on all Hyper-V Hosts using PowerShell cmdlets, and second approach can be used to figure out issues by enabling tracing on the virtualization components. In this article, we also learned that Hyper-V network virtualization configuration is lost when a Hyper-V server restarts if HNV configuration is implemented manually using PowerShell cmdlets.
In the next part of this article series, we will continue to focus on other possibilities which might cause communication failures between VM1 and VM3 and also touch upon the second approach which is to enable tracing on virtualization components to get to the root cause.
If you would like to read the other parts in this article series please go to
- Troubleshooting Hyper-V Network Virtualization (Part 2)
- Troubleshooting Hyper-V Network Virtualization (Part 3)