Hyper-V Networking 101. Part 1: NICs and Switches

Posted by Thorsten Windrath on March 22, 2017
Share on Facebook0Share on Google+0Share on LinkedIn2Share on Reddit16Tweet about this on Twitter0
4.58/5 (12)

Network cables



There are lots of posts regarding Hyper-V networking. But there doesn’t seem to be a single compiled and up to date guide covering fundamentals and some advanced topics alike. This article aims to fill that gap, without a wall of text but a few easy to understand diagrams, tables, and PowerShell snippets. We will take a look at Hyper-V’s basic networking concept, NIC teaming (Network Interface Card) and different approaches to let VMs (Virtual Machines) talk to specific VLANs or even VLAN trunks.

The first article in the Hyper-V Networking 101 series will cover everything you need to know about virtual switches and NICs. The last post is planned as a real-world example: A way to implement a secure Wi-Fi (and/or wired) guest network on top of a virtual firewall.

Physical vs. Virtual Networking

Networking in the virtual world isn’t that different from its physical counterpart. A basic VM, like any basic server, may use one (virtual) NIC that connects to a single subnet. You could add additional IP addresses to that NIC to reach even more subnets. Add additional NICs for load balancing and/or redundancy or to make your OS reach other networks. Even VLANs may be applied at any given stage. To be honest, there is absolutely no real difference that you may notice in your day to day work.

Hyper-V Networking

Hyper-V tries to keep things as simple as possible when it comes to networking. There are two logical layers between your VM and your physical uplink: A virtual NIC and a virtual Switch. The virtual switch itself is dumb, apart from a few advanced settings. There is no management interface, no Layer 3 functionality, no spanning tree configuration. It’s more like a logical abstraction layer in the background that provides network connectivity to your VMs.

Virtual Switch Types

Figure 1: Virtual Switch Types

Hyper-V provides three types of virtual switches: external, internal and private. They are nearly identical, the only real difference between the different types is optional access for the management partition and access to external networks.

Virtual switch types

Table 1: Virtual Switch Types

Please note that each physical NIC that has been bound to a virtual switch cannot directly be used for other purposes anymore.

Management partition connectivity: “Allow management operating system to share this network adapter”

Remember that Hyper-V is a type 1 hypervisor. This means that there is just a small piece of software running on the hardware and the virtual machines. And: There’s absolutely no host operating system. Instead, the management OS is simply running as a virtual machine too.

Hyper-V hypervisor vs. bare metal

Figure 2: Type 1 hypervisor vs. bare metal

This is true even if you install Windows Server with a full-blown GUI. Once you activate the Hyper-V role and reboot the host, your previous bare metal operating system will run on a virtual machine. Below is a screenshot showing a Microsoft Hyper-V Server 2016. Even this minimal interface isn’t running directly on the hardware, but inside a virtual machine – the management partition:

Microsoft Hyper-V Server Management OS

Figure 3: Microsoft Hyper-V Server Management OS

What happens in the background when you allow your management partition to access a virtual switch is simpler than you might think, and there’s absolutely no magic involved: Hyper-V just adds a virtual NIC to the VM running the management OS. That new virtual NIC will be connected to your virtual switch, as shown in the following diagram:

Management OS - just another virtual machine

Figure 4: Management OS – just another virtual machine

External Switch

Probably the most often used type. It provides access to external networks via physical uplinks, either teamed or single NIC(s). You may also allow the parent OS to access that switch. In this case, Hyper-V creates a new virtual NIC and connects that NIC to the virtual switch.

External virtual switch

Figure 4: External virtual switch


  • Remember: Your Host-OS is just another VM, even if it looks like a regular physical installation.
  • You cannot bind the same physical NIC to more than one virtual switch.

Create a new external switch using PowerShell

Please note that we do not provide the parameter SwitchType here because a virtual switch having a physical NIC is always an external switch per definition.

Internal Switch

The internal switch provides access between VMs and the parent partition. This could be used for local monitoring or backend services like databases for example, which are not supposed to talk to the outside world.

Internal virtual switch

Figure 6: Internal virtual switch

Create a new internal switch using PowerShell

Please note that we do not provide the parameter AllowManagementOS here because granting access to the management OS is not optional for internal switches.

Private Switch

Private switches are identical to internal switches. The just don’t provide access to the management partition. There are a few use cases like a heartbeat connection for clustered VMs for example. But having clustered services on the same physical host rarely makes any sense…

Better use VLANs with external switches, which will be covered in a later article.

External virtual switch

Figure 7: External virtual switch

Create a new private switch using PowerShell

Like with the internal switch, we are not using the SwitchType parameter here.

Example: A redundant virtual firewall system using CARP

The following diagram demonstrates a possible use case involving two external and a private virtual switch. For example, two pfSense firewall VMs using CARP do need a private network to sync their states and configurations.

This is not what I would call best practices, because – like I said before – redundant systems on the same physical hardware hardly make much sense (in most cases). Better use another external switch, run tagged VLAN traffic on it and have your firewall VMs deployed to different hosts. I’ll talk about that in another article soon.

Scenario with multiple virtual switches

Figure 8: Scenario with multiple virtual switches

Conclusion & Outlook

This guide’s intention is to help you to understand how Hyper-V networking works. Like I said before, we’ll slowly dive into more details soon. The next article in the Hyper-V Networking 101 series will be about different types of teamed NICs.

Feel free to leave a comment in case you have any questions – or if you would like to have a specific topic covered during this series.

Related materials:


Views All Time
Views Today

Please rate this

To download the software products, please, make your choice below. An installer link and a license key will be sent to the e-mail address you’ve specified. If you consider StarWind Virtual SAN but are uncertain of the version, please check the following document Free vs. Paid. The recent build of Release Notes. A totally unrestricted NFR (Not For Resale) version of StarWind Virtual SAN is available for certain use cases. Learn more details here.

Return to all posts

Data Management Moves to the Fore. Introduction
Veeam Backup Enterprise Manager
The following two tabs change content below.
Thorsten Windrath
Thorsten Windrath
Thorsten is a jack-of-all-trades with more than 20 years of experience, currently working at the Institute of Aircraft Cabin Systems at the Hamburg University of Technology. As a developer, he‘s focusing on demonstrators and other prototypes, often including n-tier applications, embedded systems, and cross-platform communication. Thorsten is also responsible for the institute's IT infrastructure, a full-featured network incl. modern storage and virtualization technology.

Latest posts by Thorsten Windrath (see all)