

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. Obviously, the host was unable to communicate across the network, as were the virtual machines. For whatever reason, that particular cable just went bad. In the first of those situations, there was a problem with the physical network cable on the host. 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. 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. When a virtual machine is having trouble communicating on a network, it’s a good idea to check the virtual machine’s IP address. 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. 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). This virtual network adapter was created on the Hyper-V host for use by the host operating system. You will notice in the figure that there is also a network connection called vEthernet (My Virtual Switch).

This is because Hyper-V requires exclusive control of the physical adapter. None of the usual components such as TCP/IP are enabled. The only item that is enabled on the physical network adapter is the Microsoft LLDP Protocol driver. This image was captured from the Hyper-V host. Here I have a virtual switch bound to a physical network adapter named Intel I210 Gigabit Network Connection. To see how this works, check out the image below.

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. It then creates a virtual network adapter that is used by the host operating system. 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. 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. You can see the default virtual switch and its properties in the figure below.Ĭheck the Hyper-V network adapter on the hostĪssuming 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. A private virtual switch allows communication between virtual machines residing on the host but does not allow for communication with the host operating system. Incidentally, the third type of virtual switch supported by Hyper-V is known as a private virtual switch. 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. This means that the virtual machine can communicate with the host operating system and with other virtual machines that are running on the host. The default switch connects only to the Hyper-V internal network. The reason why this was a problem was because Hyper-V supports three different types of virtual switches. 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. Just last week, I ran into a situation where one of my Hyper-V virtual machines was suddenly unable to communicate on the network. 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. 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. Hyper-V communications problems? Check the virtual switch first 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. Thankfully, when this happens, it is usually somewhat easy to correct the problem. 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.
