Troubleshooting Hyper-V communications problems

One of the more common problems that IT admins sometimes experience in Hyper-V is a virtual machine’s inability to communicate on the network. Thankfully, when this happens, it is usually somewhat easy to correct the problem. In this article, I will show you a few of my favorite tricks for figuring out why Hyper-V virtual machine communications are breaking down.

Hyper-V communications problems? Check the virtual switch first

If you have a Hyper-V virtual machine experiencing problems with the network communications, then the best place to start your troubleshooting efforts is by looking at the virtual switch.

If your other virtual machines are working properly and use the same virtual switch as the virtual machine experiencing issues, then the virtual switch is probably fine. However, it is still worth checking. Just last week, I ran into a situation where one of my Hyper-V virtual machines was suddenly unable to communicate on the network. When I took a look at the problem, I quickly realized that while making another change to the virtual machine’s configuration, I accidentally assigned the virtual machine to the default virtual switch.

The reason why this was a problem was because Hyper-V supports three different types of virtual switches. The default switch connects only to the Hyper-V internal network. This means that the virtual machine can communicate with the host operating system and with other virtual machines that are running on the host. If a virtual machine is to communicate with the Internet or with machines on the physical network, it needs to be connected to an external virtual switch. Incidentally, the third type of virtual switch supported by Hyper-V is known as a private virtual switch. A private virtual switch allows communication between virtual machines residing on the host but does not allow for communication with the host operating system. You can see the default virtual switch and its properties in the figure below.

Check the Hyper-V network adapter on the host

Assuming that everything is all right with the virtual switch, the next thing that I recommend checking out is the physical network adapter configuration within the parent operating system. The reason why this is so important is because when you create an external Hyper-V virtual switch, that switch gets bound to a physical network adapter. In doing so, Hyper-V changes the network adapters’ configuration in the host operating system so that the network adapter will only work with Hyper-V. It then creates a virtual network adapter that is used by the host operating system. This virtual network adapter actually connects to the Hyper-V virtual switch, meaning that both the host operating system and the virtual machines share a common Hyper-V virtual switch, which is in turn bound to a physical network adapter.

To see how this works, check out the image below. Here I have a virtual switch bound to a physical network adapter named Intel I210 Gigabit Network Connection.

Now take a look at the next screenshot. This image was captured from the Hyper-V host. The only item that is enabled on the physical network adapter is the Microsoft LLDP Protocol driver. None of the usual components such as TCP/IP are enabled. This is because Hyper-V requires exclusive control of the physical adapter.

You will notice in the figure that there is also a network connection called vEthernet (My Virtual Switch). This virtual network adapter was created on the Hyper-V host for use by the host operating system. This is the adapter that must be used when configuring the host’s network connectivity (such as the host’s IP address and DNS server assignment).

I am showing you all of this because you can break network connectivity if you disable either of these network adapters or if you try to reconfigure the physical adapter that is bound to the Hyper-V virtual switch.

Checking the IP address

When a virtual machine is having trouble communicating on a network, it’s a good idea to check the virtual machine’s IP address. However, one thing to remember is that just because a virtual machine is not receiving an IP address from your DHCP server, it does not mean that the virtual machine is misconfigured. I can think of two situations where I have seen virtual machines and hosts that were configured 100% correctly fail to acquire an IP address.

In the first of those situations, there was a problem with the physical network cable on the host. For whatever reason, that particular cable just went bad. Obviously, the host was unable to communicate across the network, as were the virtual machines. It just so happened that the problem was first noticed within a virtual machine, which made it seem as though it was the virtual machine that was having the problem when in reality, it was the host and everything on it.

In the other situation, the DHCP server responsible for provisioning virtual machines with their IP addresses had its IP address pool completely depleted. Because the DHCP server ran out of IP addresses, it had none left to allocate to the virtual machine in question.

The easiest way to find out whether or not a Windows virtual machine has received an IP address is to open a command prompt window within the virtual machine and then enter the ipconfig command. This will show you the IP address that has been assigned. If you need more detailed information, you can append the /ALL switch to the ipconfig command. Additionally, you can use the Ping command to test the virtual machine’s ability to communicate with other virtual machines on the network. You might start by pinging an IP address, but you can also test DNS resolution by attempting to ping a machine by its fully qualified domain name.

Hopefully, with these tips, you can find and correct your Hyper-V communications problems.

Featured image: Shutterstock