If you would like to read the first part in this article series please go to:
- Virtual Networking for Hyper-V (Part 1)
- Virtual Networking for Hyper-V (Part 3)
- Virtual Networking for Hyper-V (Part 4)
- Virtual Networking for Hyper-V (Part 5)
- Virtual Networking for Hyper-V (Part 6)
Introduction
In the first part of this article series, I talked about the roles of the physical network adapter and the virtual network adapter within a Hyper-V parent partition. I also briefly discussed the virtual switch. In this article, I want to continue the discussion by talking about the role of the virtual switch in more detail. As I do, I will also show you how child partitions fit into the picture.
A Quick Review
Before I get started, I want to quickly review the way that network adapters function within the parent partition, because understanding this concept is essential to understanding the other things that I want to show you.
What you need to remember is that even though the parent partition and its Windows Server 2008 operating system can see the physical network adapter, they do not use it directly. Instead, the TCP/IP stack is only bound to the virtual network adapter. The virtual network adapter passes packets to and from the physical network adapter by way of a virtual switch, as shown in Figure A.
Figure A: Applications running in the parent partition do not use the physical network adapter directly
The Virtual Network Switch
As you can see in the figure above, the virtual network switch serves as a link between the physical and the virtual network adapters. Before I get into an explanation of what the virtual switch does, I need to point out that the architecture shown in the figure above isn’t used in every single case.
In the previous article, I showed you how Windows had automatically reconfigured the bindings for my Hyper-V server’s physical network adapter so that the only remaining binding was to the Microsoft Virtual Network Switch Protocol. I also showed you that TCP/IP was completely disabled on the server’s physical network adapter.
In reality though, this type of configuration isn’t an absolute requirement. You can enable all of the usual bindings for a physical network adapter (within the parent partition), but there is a catch. You should only enable those bindings if the network adapter will be dedicated to serving the parent partition only. Otherwise, the adapter needs to be configured in the way that I showed you in the previous article.
Microsoft allows you to dedicate a physical adapter to the parent partition. This is typically done for performance reasons. By dedicating a physical adapter to the parent partition, traffic flowing between the parent partition and the physical network can be offloaded to the dedicated network adapter, while network traffic related to the child partitions flows through a different adapter.
Dedicating a physical network adapter to the parent partition requires you to disable the Microsoft Virtual Network Switch Protocol for that adapter. Since the network adapter is not connected to a virtual switch, Hyper-V does not bind the virtual network service to that adapter which improves performance by reducing overhead. It also ensures that the adapter will not service any of the traffic related to virtual servers running in the child partitions.
If you look at Figure B, you can see a simplified diagram depicting the parent partition of a Hyper-V server. The server in this diagram has two physical network adapters. One adapter is tied into the virtual network switch, and the other is not. While both adapters are capable of servicing the parent partition, the adapter that is connected to the virtual network switch will also service any child partitions that might be created.
Figure B: Not all physical network adapters have to be tied to a virtual network switch
Child Partitions
Now that I have talked about the way in which the parent partition is tied to the virtual network, I want to turn my attention to the child partitions. If you look at Figure C, you can see a diagram in which I have depicted the parent partition alongside a child partition.
Figure C: This diagram illustrates how the parent partition interacts a child partition
This diagram illustrates how the parent partition interacts with the child partition. Before I begin describing how this interaction takes place, I want to point out that I have further simplified my diagram of the parent partition in order to make it easier to focus on the way that the parent partition interacts with other partitions. Specifically, I have omitted the virtual network adapter and the TCP/IP stack from the parent partition in my diagram. If this were a real network, those components would still exist and would continue to function in the manner that I described in the previous section. I simply omitted them in an effort to prevent my diagram from becoming too cluttered.
With that said, you can see that the way in which the child partition interacts with the parent partition is pretty simple. The child partition has its own virtual network adapter, and it connects to the virtual switch that’s located in the parent partition. This allows the child partition’s network adapter to pass traffic through the physical network adapter.
The child partition’s virtual network adapter is configured in a manner similar to the way that a physical network adapter might be configured on a non virtualized server. To see what I mean, take a look at Figure D.
Figure D: There is nothing special about the way that a virtual network adapter is configured in a child partition
As you can see, the figure above displays the Local Area Connection Properties sheet. This screen capture was taken from virtual server that was running a Windows Server 2008 operating system. As you can see, all of the usual bindings are enabled, just as they would have been if this operating system had been installed directly onto a physical server rather than in a virtualized environment. Likewise, the virtual machine has been configured with its own unique IP address.
Another thing that you might notice about the figure above is that there is no binding to the Microsoft Virtual Network Switch protocol. You may therefore be wondering how the virtual network adapter connects to the virtual switch.
The connection is based on the adapter’s name. The virtual network adapter’s name conveys the virtual switch that the adapter is connected to. For example, if you look at Figure E, you can see a virtual network adapter named Local Area Connection.
Figure E: This virtual network adapter is named Local Area Connection
When I view the corresponding switch through the Hyper-V Manager, you can see that the switch is named Local Area Connection – Virtual Network. In essence, the virtual network adapter’s name matches the name of the switch that it is connected to.
Figure F: The virtual network adapter’s name matches the name of the switch that it is connected to
Conclusion
The simple fact that the virtual network adapter’s name is based on the name of the virtual switch that the adapter is connected to implies that there can be more than one virtual switch. I will show you the benefits of using multiple virtual switches in Part 3.
If you would like to read the first part in this article series please go to:
