John Howard - Senior Program Manager in the Hyper-V team at Microsoft

Senior Program Manager, Hyper-V team, Windows Core Operating System Division.

How does basic networking work in Hyper-V?

How does basic networking work in Hyper-V?

  • Comments 89
  • Likes

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”.

  • When adding the Hyper-V role in a full installation of Windows Server 2008, you have the option to create one or more external virtual network switches. (This option is not available in server core installations of Windows Server 2008). I’m going to assume that no external virtual network switches were created during installation, and the Hyper-V role is enabled.
  • Our recommendation, in a simple deployment, is to have at least two physical NICs in a physical machine– one (or more) dedicated to the physical machine, and one (or more) for virtual machines. The reason will become obvious as you work through this post.

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.

  • We created a new virtual network switch with two ports.
  • We added another NIC to the physical computer (it just happens that it’s a Virtual NIC, not a physical NIC)
  • We logically labeled the switch “Test External Network”.
  • We ran a couple of bits of “virtual” network plumbing
    • A pseudo virtual CAT5 cable from the virtual network switch to the physical NIC. (*)
    • A virtual CAT5 cable from the Virtual NIC into the virtual network switch
  • We re-jigged some network bindings.

(*) 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:

  • Ping uses the Windows networking stack to determine where the IP protocol is bound. There is only one choice – it’s on the Virtual NIC.
  • An IP packet is sent down to the networking stack bound to the Virtual NIC. This is the flow labeled “1”.
  • The Virtual NIC has a bit of virtual CAT5 cable plugged into it. The virtual NIC does what any physical NIC would do:  Put the packet on the (virtual) wire. This is the flow labeled “2”.
  • The other end of the virtual CAT5 cable is plugged into a (virtual) port on the Virtual Network Switch called “Test External Network”. The packet appears at the switch port.
  • (Simplying again…) The Virtual Network Switch does what a physical counterpart would do and routes the packet to its destination. Without going into the detail of routing and learning algorithms, suffice to say it makes the packet makes it’s way to the other virtual port on the switch, coloured in blue. This is the flow labeled “3”.
  • At this point, remember that we’re dealing with a virtual network switch. This switch knows about the Microsoft Virtual Network Switch Protocol, and can therefore do some “magic” in software. The magic is basically getting the packet to the physical NIC. That’s the flow labeled “4”.
  • Once on the physical NIC, we’re down to physical networking, so the flows marked 5 and 6 show the data entering the physical world in the form of a Physical Network Switch and then onwards to some other server.
  • A packet coming the other way follows the same path in reverse.

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.


P.S. Thanks to my colleague, Keith Mange, for his assistance with this post :)

  • PingBack from

  • Hi John,

    wow, thanks for this impressive overview of the networking feature within Hyper-V, real good job!

    Greetings from Austria (not Australia) *gg*

    Peter Forster

    MVP Virtual Machine

  • I had a discuss a couple days ago at TechEd with some people about Blogs and what information was "appropriate"

  • Hi, I followed your excellent instructions on getting Hyper-V to work on a Server Core installation.  I'm now running two Server 2008 VMs on it, and they seem to run great.  Thanks!

    I recently created a Ubuntu Server VM to host a wiki, and it runs really slow.  Could this be because I have only one NIC in the server?  The wiki on the Ubuntu server is using a DB on one of the Server 2008 VMs.  Or is the slowness probably just that the Ubuntu server doesn't have the advantage of integration services?  How would I go about measuring for the bottleneck?  Thanks for any tips.

  • If you followed yesterdays post explaining the basics of networking in Hyper-V, you may be wondering

  • Lance - I confess, I've never installed or run Ubuntu. Emulation will be relatively significant in terms of overhead compared to synthetic devices, particularly on the send path (receive is somewhat better than send). Can you define a little clearer what "slow" means? On receive, on send? Have you looked at the logical processor and virtual processor counters in perfmon in the root partition - they may give some indication if you are bottlenecked on CPU. Have you compared performance between a supported child operating system and Ubuntu?

    Having only one physical NIC won't affect performance of networking in a virtual machine - however it's not recommended as it affects networking  performance from the root partition. Have you tried running a steady n/w load test inside the VM to measure the throughput and/or LP load?

    One other thing - what sort of physical NIC is in the machine. Could it be a case of needing later drivers for the physical NIC or changing the offload settings for it. I've seen a few reports (on Dell 2950s with Broadcom Nics IIRC) that offload settings can affect network performance.



  • While it is possible to create some complex networking environments in Hyper-V, the basic concepts are

  • Hi John.

    In you article there is no mention to subnets. Indeed if you create two Internal (or Private) Networks in H-V and put two Virtual machines on separate IP Subnet they cannot communicate each other. In other words, the virtual switch works at level 2 only.

    Is there a way to have a layer 3 routing within H-V? I need this cause i'm trying to simulate a scenario with a DMZ and a LAN using one Host only.

  • Getting Started with Microsoft Hyper-V Understanding Hyper-V partitions and device drivers Migrating

  • Simone - indeed, you are correct and that was deliberate. So far, I was just explaining the possible traffic flows under different circumstances. However, yes, you are correct, virtual network switches operate at level 2 in the OSI stack, below TCP/IP. To achieve routing at higher levels, you need to use a router, the same as you do in a physical environment. You can use ISA 2006 to achieve this very successfully using Hyper-V (I have run this many times in a variety of scenarios).



  • U zadnje vrijeme sam imao podosta obaveza pa ne stigoh osvjeziti blog novostima, stoga slijedi izvjestaj

  • With the RTM release of Hyper-V just around the corner, I thought it would be a good idea to re-visit

  • John,

    If I look at the tcp/ip properties of the host/root partition's virtual NIC, they are unusual -  using a 169... address that our DHCP servers certainly didn't give out, no default gateway, etc.  Is there any reason to ever touch this NIC's configuration?  Is it a good idea or a bad idea to remove this virtual NIC if there is a 2nd physical NIC for host machine traffic (and assuming we will not use internal or private configs)?



  • Martin - 169.x.x.x address are APIPA address and get assigned when you can't get a "real" IP address from a DHCP server. The most common reason is an unplugged network cable. Before you created the external switch, were you able to get a "real" IP address on that physical NIC? That would rule out a faulty network cable.

    As for touching the configuration on the virtual NIC - that's really so dependent on what you're trying to do and how your environment is setup. When you have a second physical NIC though, you probably don't even need a virtual NIC on the first external switch - you really want a "dedicated" switch where no virtual network is present (see my related second post - explains that a little more).



  • John,

    Not sure what the sequence would have been in my existing case.

    In general, if I have a physical NIC with a valid, complete tcp/ip config, and I create a external virtual network using that NIC, should the resultant virtual NIC adopt the tcp/ip config of the physical NIC?

    Also, re your second post, any guess when we would have info on how to create a dedicated switch?



Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment