If you’ve ever worked with Microsoft’s Virtual PC or Virtual Server, then you know that those products work in the same way as any other Windows application. They sit on top of the host operating system, and all of the virtual machine’s hardware calls are passed through the host operating system, which manages the server’s hardware usage. Hyper-V takes a completely different approach to virtualization though, and this means that network communications are implemented in a much different way than they were in Microsoft’s other virtualization products. In this article, I will show you how networking works in Hyper-V.
The Virtual Switch
What really sets Hyper-V apart from Microsoft’s other virtualization products is that virtual machines perform much better because they can communicate with the server’s hardware directly rather than having to pass hardware requests through the host operating system (although there are some exceptions to this). Of course you can’t just bombard a network adapter with simultaneous traffic from multiple virtual machines. There has to be a way of managing the traffic. To get around this problem, Microsoft has introduced the concept of the virtual switch.
To understand how this is possible, you have to realize that Hyper-V is not a Windows Server 2008 add-on, but rather is a part of the operating system. When you install the Hyper-V role, the hyper visor is placed “underneath” the Windows 2008 operating system. The existing operating system (known as the host operating system) is placed into something called the parent partition, and each guest operating system is placed into a separate child partition.
To make this type of architecture possible, Microsoft had to unbind the host operating system’s TCP/IP stack from the server’s NIC. In doing so, they have created an additional layer of abstraction known as the virtual switch. The virtual switch is the only networking component that is bound to the physical network adapter. The parent partition and the child partitions use virtual network adapters (known as vNICs), which communicate with the virtual switch using Microsoft’s Virtual Network Switch Protocol.
I realize that this description may be difficult to follow, so I have created the diagram shown in Figure A as a way of helping you to understand the architecture.
Figure A This is what the virtual switch architecture looks like.
Additional Virtual Switches
Hyper-V allows you to create additional virtual switches beyond the one that I just talked about. To do so, open the Hyper-V Manager and then click on the Virtual Network Manager link. Upon doing so, Windows will display the Virtual Network Manager screen, shown in Figure B.
Figure B The Virtual Network Manager allows you to create additional virtual switches.
If you look at the figure above, you can see that the default virtual switch is bound to my physical network adapter. You also have the option of creating a new virtual network, which is the same as creating a new virtual switch. As you can see in the figure, there are three different types of virtual networks that you can create.
Your first option is to create an external virtual network. Doing so creates a virtual switch through which virtual machines can access your entire network, and even the Internet assuming that you have the necessary infrastructure in place.
One thing that you do need to know about external virtual networks is that they must be bound to a physical network adapter. Additionally, each physical network adapter can only be used for a single virtual network. Therefore, if you are creating a secondary external virtual network then you're going to need a secondary NIC that you can bind the new external virtual network to.
Your next option is to create an internal virtual switch. An internal virtual switch is not capable of accessing the yarn that, or even your private network as a whole. It serves primarily as a mechanism for allowing communications between the virtual machines that are hosted on the server. Additionally, an internal virtual network can facilitate communications between the host operating system and the guest operating systems that are running on it.
Your third option is to create a private virtual network. A private virtual network can only be used to facilitate communications between the virtual machines that are hosted on the current server. Private virtual networks can not access the outside world, nor can they access the host operating system.