Hyper-V Networking

Every Virtual Machine needs basic Internet access to apply maintenance, add optional features, and install programs and libraries. Hyper-V has a built in Default network that provides VMs with general network access without any configuration because it runs through a gateway in your native Windows 11 system and piggybacks on the networking you already have.

In technical terms, Default provides each VM with network addresses and parameters through DHCP, resolves network names on your host, provides a NAT gateway on the host, and uses the host routing tables to select the best choice from your wired, wireless, or VPN connections. There is no better solution for basic client access from any VM.

With a connection to Default, a client program on the VM can access anything on the host computer, the local network (home or Yale), any VPN your computer is connected to, and the general Internet. Default allows client programs on the host computer to dynamically find and connect to VMs by hostname (using “hostname.local” dynamic name resolution).

You need a custom network to give a VM a static IP address, to expose services running on a VM to clients on another computer, or to make a VM look like a normal computer on your local network.

Hyper-V is not “Bare Metal” Virtualization

In large datacenters virtual machines are created by specialized hardware. These systems can have special network adapters that allow virtual machines to communicate directly at the hardware level.

Hyper-V can work on any computer that supports Windows, and it can run on any network adapter that runs with Windows, including adapters connected through USB or on a docking station. It emphasizes generality over optimization, so it cannot connect any hardware device directly to a VM. It is, however, built into the Windows Kernel rather than running as an application program.

The network adapters are installed into Windows, have Windows drivers, and appear in the Windows Device Manager. They may have hardware optimizations that can be turned on or configured on the host system. Most users will ignore these options, but anything configured in the native Windows system will also apply to all VMs.

Open

Generic Virtual Network Adapters

The interface between an operating system and a network device drive is fairly simple, and many different types of software will generate what appears to be a network adapter but is really some type of software service. VPN software creates a simulated direct network connection to the campus, but actually sends the data on an encrypted session over the public internet. Simulated network adapters are part of WSL, Docker containers, and other software.

Hyper-V, like most virtual machine supervisors, has created its own virtual network device drivers that will be installed automatically when a Windows or Linux system discovers that it is running in a Hyper-V VM. Instead of simulating a hardware device, network communication is handled by translating software calls from the operating system in the VM to software calls from the VM to Hyper-V itself.

A Linux application does a system call to the Linux kernel, which then calls the Linux Hyper-V network device driver, which then calls out from the VM to Hyper-V running in the real computer. Hyper-V then processes the request by moving the data to another VM or to the host Windows system, where it will either be fed up through another Hyper-V device driver or passed to the Windows device driver of a real physical network adapter card.

Hyper-V allows Windows to share a physical network adapter with Hyper-V virtual machines. To do this, Hyper-V “splits” the physical adapter into two devices. In the following example, a Windows system originally had a Realtek USB network adapter named Ethernet 2 connected through a local network to the Internet. Then this adapter was shared with Hyper-V so VMs could also use it.

Open

Hyper-V created a new pure software simulated network adapter called “vEthernet (Bridge)”. It is not obvious from this display, but vEthernet (Bridge) and Ethernet 2 are actually the same device. The Ethernet 2 device is still the Realtek USB adapter connected to an Ethernet wire, but it now provides network access for both the host Windows system and any VM configured in Hyper-V to also use it. The host Windows system is configured is now only one of the operating systems using the physical adapter, so the new virtual vEthernet (Bridge) device holds the Internet configuration parameters (IP address, Ethernet ID, name server configuration) that is specific to the Windows host and is different on each VM.

The Virtual Switch Meme

Hyper-V networking has the same services and configuration options as competing options like VMware Workstation or Oracle VirtualBox. Other systems may create a named “virtual network” and then connect virtual adapters on each VM to that network by its name. Hyper-V does the same thing, but Microsoft has decided to call it a “virtual network switch” instead of a “virtual network”.

The only advantage of this meme is that a switch is a physical device in the real world, and when you are drawing diagrams in a tool like Visio, you can find a standard picture for a switch and add it to your diagram along with pictures of real or virtual computers connected to the switch:

Open

However, Hyper-V does not emulate some of the more technical behavior of a physical network switch, so if you make the mistake of expecting real switch behavior, it doesn’t work that way.

How it Really Works

Inside the Kernel of the operating system, there is software that wraps the data into a TCP “packet” associated with a port number destination with data that supports recovering if packets are lost or reordered. The TCP packet is then broken into IP packets with the IP address of the sender and destination. The IP packet is then broken into one or more Ethernet packets with the 6-byte Ethernet ID of the sender and destination on the LAN.

Up to this point everything has been universal and hardware independent. The next step depends on whether the data is going over a wire, Wi-Fi, or Bluetooth, what chip is used, is it on the motherboard or USB, and many other things.

The best strategy is to stop with an Ethernet packet sitting in memory in the Kernel of some operating system. It has a 6-byte destination Ethernet ID, and Hyper-V knows every 6-byte Ethernet ID of every virtual adapter on every VM or on every virtual device it created in the host Kernel. If it finds a match, then it knows where to move the packet so the receiving operating system can process it. If it cannot find a match, but the switch is associated with a physical network adapter, then the packet can be queued up in the host Windows system to be transmitted out to the external devices on the physical network.

Configuring Hyper-V Virtual Switches

Every time your computer boots up, Hyper-V recreates and configures the Default Network/Switch. It has no configuration because it uses all the network configuration of the Windows host system to resolve names and route traffic through the fastest available network path. If you try to mess with it or delete it, it will be recreated fresh when you restart the system.

Other Virtual Switches can be configured using the graphic tool named Hyper-V Manager or by typing PowerShell commands into a Run as Administrator PowerShell session.

PowerShell is probably not the option you will choose, but it provides an example of starting with the simplest possible configuration and then adding feature to it step by step.

Create

To create a naked Switch with nothing attached to it, you provide a Name. This simplest option is not the default for the command, so you add the “-SwitchType Private” option or the command will complain that you have forgotten other parameters

A naked switch can be connected to virtual network adapters on VMs so they can communicate with each other.

Add the Host

Hyper-V has decided that a virtual switch that includes a dummy device in the host Windows Kernel so that the host can communicate over this network to the VMs is identified by “-SwitchType Internal” instead of Private. You could have created the switch this way in the previous command, or you can change the type of the previously created switch with Set-VMSwitch. In the following example that command is followed with a command to show the Hyper-V Virtual Ethernet device created in the host Windows system to allow the host applications to talk to the VM. Note that the virtual device name includes the Switch name:

Note that there is an unused Intel physical adapter named “Ethernet” that will be used in the next example.

Problem Adding a Physical Adapter to an existing Hyper-V Switch Network

Once you create a Private or Internal switch you can then connect it to VMs and configure them with network addresses so they can talk to each other. Suppose you assign them to the 192.168.10.* subnet.

A physical adapter is connected to external devices that are part of some physical network. Let us assume that network is configured to use the 192.168.3.* subnet.

Adding the physical adapter to the internal Hyper-V network would “bridge” two different networks with two different subnets. You would have to reconfigure everything on one of the two networks before they could really talk to each other.

This is not a problem when the existing Hyper-V switch is not connected to any VM and therefore has no subnet, or if the physical network adapter is not plugged into anything and therefore has no external subnet, but neither PowerShell nor Hyper-V Manager know this and there is no option to tell them it is OK.

As a result, you should never try to connect a physical adapter to an existing Hyper-V virtual switch. Virtual stuff is free. You will get a clean solution if when you want to attach a physical adapter to Hyper-V, you use it to create a new switch, which will have a SwitchType of External. Then if you want some VMs to have access to the physical network, create additional virtual network adapters in the VM and connect the new switch to them leaving in place any existing virtual adapters connected to existing Internal or Private switches.

Create a new switch from the Intel adapter named “Ethernet” that was displayed in the previous example, and share it with the host Windows system:

Hyper-V Manager Switch Configuration

In the Actions menu, click on Virtual Switch Manager …

In this panel there is an entirely useless option list asking what type of Switch you want to create.

Open

It is useless because all it does it set the default choice among three radio buttons on the next form, but you can always change that selection before you click the create button:

Open

Using Hyper-V Manager you don’t have to remember PowerShell commands or the names of options, and you get a nice pulldown list of physical Ethernet adapters on the host system.

Note: this list includes adapters that are already being used with other switches and cannot be selected or you will get an error message instead of creating the switch.

Virtual Network Adapters in each VM

Each Hyper-V VM has a configuration including virtual disks and virtual network adapters. Each virtual disk is associated with a *.vhdx or *.iso file somewhere on the host disk, and each network adapter is either unconnected or connected to a named Virtual Switch.

Open

Here there are two network adapters. The first adapter is connected to the Hyper-V Default switch/network. The second is connected to a Switch named “Bridge”. At any time you can disconnect a Virtual network adapter or connect it to another Switch. This simulates unplugging the Ethernet cable from a real computer and plugging in a cable connected to something else.

At any time you can add a new Network Adapter.

Open

Adding an adapter to a running VM will work if the operating system reacts to the kind of hardware changes that happen when you plug a physical adapter into a USB port.

Once the adapter is defined, at any time you can connect or disconnect or change the virtual switch to which the adapter is attached. This is equivalent to plugging or unplugging an Ethernet cable to a physical adapter.

Open

VLANs

If you don’t know about VLANs or do not use them, ignore this.

Since Hyper-V switches are themselves virtual, you can create as many as you want. The only use for VLANs is when you have a physical network adapter connected to a switch that is connected to a network that not only supports VLANs but where the connection to the adapter is configured as “tagged” (meaning that the adapter can send Ethernet packets with a prefix that selects which VLAN the packet is associated with).

Each VM virtual adapter can be configured with a specific numeric VLAN number, and if the host is sharing use of this physical adapter, then its dummy network adapter connected to the virtual switch can also be assigned a VLAN ID number.