Virtual Networking for Hyper-V (Part 2)

by [Published on 11 Aug. 2010 / Last Updated on 11 Aug. 2010]

This article continues the discussion of virtual networking for Hyper-V by examining how network communications occur between partitions.

If you would like to read the first part in this article series please go to:

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.

Virtual Network 2A.jpg
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.

Virtual Network 2B.jpg
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.

Virtual Network 2D.jpg
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.

Virtual Network 2E.jpg
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.

Virtual Network 2F.jpg
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:

Advertisement

Featured Links