While it is possible to create some complex networking environments in Hyper-V, the basic concepts are relatively straight forward. This post walks some simple scenarios and how the main components operate in terms of the flow of data. Let’s start by setting a level playing field and a “best practice”.
To constrain the starting point, I’m assuming (for simplicity, not by recommendation) the physical machine contains a single physical NIC. If you open Network Connections (Start/Control Panel/Network and Sharing Center, or Start ncpa.cpl), you would see something like below – a single connection.
And to get some more information, I’ve used View/Detail in the next screenshot: Let’s look at the network bindings by selecting the NIC, right-clicking and choosing properties. Notice that (in this simple example), all protocols are bound to the NIC except the Microsoft Virtual Network Switch Protocol. Let’s see what changes when we create an External Virtual Network Switch. Here, I’m using Hyper-V Manager, selected Virtual Network Manager, added an External Virtual Network named “Test External Network” and selected my single Physical NIC in the drop-down. On hitting apply, you will get a warning that you may temporarily lose network connectivity while we reconfigure everything. Now let’s go back to Network Connections and see what has changed. Notice that there are now two network connections listed, but with different Device Names. Let’s look at the top one first which has the device name matching the type of physical device and open the properties to examine the bindings. Notice that nothing is bound except the Microsoft Virtual Network Switch Protocol. Now let’s open the other bottom one which has the device name matching the name I entered when creating the external virtual network switch, “Test External Network”. Notice that everything is bound except the Microsoft Virtual Network Switch Protocol. So what does this mean? Well, to explain, let’s take a physical switch. Let’s pretend it’s a simple “unmanaged” switch – the type you can buy as a commodity $30 device down at your local computer store. It typically has 8 ports on it. You can’t add ports to it. You can’t take them away. It has, and will only ever have 8 ports. Now go “virtual” for one moment and in your mind create a Virtual network switch. It’s still conceptually a box with ports. Where things get a little different is that in the virtual world, ports can be added and removed dynamically as needed, without the need for a soldering iron. Now let’s map this into what we just did above.
(*) Bear with me on this point – it will make sense soon why there’s some software magic in this bit of virtual cable. Obviously words are nowhere as easy to understand as a picture. Here’s what we’ve done:
On the top right, there is a networking application. Let’s assume it’s “ping”. What ping does is send a IP packet out to somewhere, and waits for a response to come back. With some gross over-simplification, here’s the steps:
Now as I said, I’ve over simplified. Let’s take a look at one aspect of this model. First, you’ll notice that I’m running the networking application, ping, on the physical computer, not in a virtual machine. Notice that all networking traffic from the physical computer is going through the Virtual NIC and the Virtual Network Switch. Hopefully, it therefore becomes obvious why I stated at the top that it is our “recommendation to have at least two physical NICs in a physical machine.
Here’s the diagram where two physical NICs are in the physical machine, and a single external Virtual Network Switch has been created: If a networking application running on the physical computer, or parent partition to put it into Hyper-V terminology, tries to access a separate physical server, the path to get “out” is much shorter. Of course, the astute among you may have noticed that there’s a second longer path as shown below:
Whereas this alternate path may be used while the networking stack has not learnt the best (least cost) route, it will generally only be used for a very short period of time. As soon as the least cost route is learnt, the first path with be used. As we’ve covered the basics from the parent partition perspective, let’s introduce a virtual machine. After all, chances are if you’ve read this far, you want to know how virtual machines interact. Here’s an extension to the previous diagrams. At the top, we have a virtual machine with a virtual NIC. To distinguish this virtual NIC from the Virtual NIC in the parent partition, I’ll call it a Virtual Machine NIC. It doesn’t matter if this is a “synthetic” or “legacy” network adapter from the virtual machine configuration perspective; the concepts for data flow are the same. The Virtual Machine NIC has a virtual piece of CAT5 cable connected from it to a new port on the external virtual network switch. In the diagram, a networking application is running in the virtual machine and trying to connect to something externally. The data flows are very similar to before and hopefully the diagram speaks for itself.
You may ask, what if the virtual machine is communicating with the parent partition? Well, there’s two options for this, again the actual one used is a routing decision, but this time inside the Virtual Network Switch. Let’s start with the longer route where the packets from the virtual machine are sent out on the physical wire. Here, the physical switch routes the packets back up to the server using Physical NIC #2.
And in the more efficient route: The essential difference between the last two diagrams is what happens inside the Virtual Network Switch. In both cases, it’s the flow labeled “3” which is interesting. The Virtual Network switch includes a learning algorithm. When it knows the most efficient virtual switch port to direct traffic to, it will do exactly that. However, for a short period of time, it does not know, so will act as a “hub” rather than a switch and send packets out on all virtual switch ports. Cheers, John.
P.S. Thanks to my colleague, Keith Mange, for his assistance with this post :)