Every Virtual Machine runs an operating system that needs to apply monthly maintenance, add optional features, and install programs and libraries. Today all this basic maintenance is done through the Internet.
Hyper-V has a built in Default network. “Default” is its explict name, and it is also the default network for new VMs. It is created by Hyper-V when Windows boots up.
The Default network supplies network addresses and other parameters though DHCP to each VM. It provides a DNS service that resolved names by querying the Windows host operating system for name information. It provides a gateway function (NAT) that receives packets and forwards them to other computers and the internet using the best routing logic of the host Windows system. It automatically switches between wired, Wi-Fi, and VPN when the host switches, and roams between access points as you move from room to room.
You cannot replicate all the things that Default does yourself. As a result, unless you have to test a special VM configuration that only supports some other network connection arrangement, the recommendation is
Normally connect the first network adapter on a generic VM to the Default network and let it dynamically configure itself. Then if you need something else, create additional network adapters connected to custom network configurations. The Default network will provide service if your computer has any network access.
A client program running on a VM can use Default to get to the host computer, the local (home or Yale) network, the Cisco VPN, and the Internet. A client program running on the host computer or on a VM can access another VM by using its hostname followed by “.local” (although to make this work, a Linux VM may have to install the “avahi-daemon" package if it is not installed by default).
The Hyper-V “Virtual Machine Connection” program provides on your Windows desktop a simulation of a screen, keyboard, and mouse directly connected to any virtual machine without using any simulated networking.
Hyper-V custom networks are needed if a VM needs a permanent static IP address, or is to appear to be a separate real computer on a physical local network, or if you need special routing other than the host default.
If you never expect to have any of these requirements, you can stop reading here.
Hyper-V is not “Bare Metal” Virtualization
In a Datacenter run by a university, company, or cloud vendor, there are large specialized systems that create hundreds of virtual machines. For large applications they may dedicate a physical disk or disk partition to the exclusive use of one VM. They may also provide specialized network adapters that each behave as if they were dozens of separate devices, and each simulated device can be hardware attached to a specific VM. The VM talks directly to the adapter and therefore needs a driver for that type of device.
Hyper-V runs on any desktop or Laptop Windows 11 system. It has no custom hardware. It supports just the standard Windows device drivers. This means that no VM will ever talk directly to dedicated hardware. VMs talk to Hyper-V, Hyper-V in the host Windows 11 Kernel talks to the standard Windows drivers for that device on the host system, and the Windows device drivers talk to the hardware.
Each model of each vendor’s network adapter card or chip has tuning parameters, or optional optimization features that an expert may choose to configure to optimize performance when the adapter is dedicated to a specific application or use. Most people don’t ever look at them, and few people understand how they work. The Windows Device Manager will display and set them, but in a desktop or laptop computer the general-purpose defaults are usually best:
This hardware configuration can be done in Device Manager on the host Windows 11 system. Hyper-V and the VMs have no visibility to the actual hardware.
Generic Virtual Network Adapters
All VM supervisors create in the VMs a single type of emulated virtual network adapter. When PC virtual machines was a new idea, the system emulated some simple, cheap, universally supported network adapter card for which all operating systems already had drivers. However, it is expensive to simulate the low level behavior of hardware chips. Today all VM supervisors create an entirely imaginary simple high level network adapter card, and they generally write and distribute their own device driver for Windows, Linux, and as many other operating systems as there is market share. They make the source available so developers of any other operating system can write their own drivers.
These drivers simply make a software system call to Hyper-V in order to communicate over the network.
In addition to a driver that runs when Windows is running in a VM, Hyper-V has a different driver that can be used on the host Windows 11 operating system. This driver runs in the host Kernel and makes calls to the Hyper-V component also running in the host Windows kernel.
These virtual network adapters support the standard interface used by that operating system to configure networking parameters. Each network adapter has a 6-byte Ethernet address, and while it may be automatically configured from the network, it may also be statically configured with an IP address, gateway address, and DNS servers and default suffix strings. The host Windows system can set these values, and each VM can set its own values.
Developers may turn Hyper-V on immediately on any new computer. Others may start with a simple Windows machine, configure networking the way they want it, and then enable Hyper-V later on.
While you might add a new adapter for Hyper-V, it is often easier to share an existing already configured network adapter with Hyper-V and its virtual machines. When you do this, Windows splits the physical adapter into two Windows Devices that show up separately in Device Manager and Network Connections.
Above is a display of the Network Connections after Ethernet 2 (a Realtek USB controller) was shared with Hyper-V. The original Ethernet 2 hardware device remains, but it is no longer connected to the Internet. A new Hyper-V Virtual Ethernet Adapter was created by Hyper-V. The host Windows system is now connected to the Internet through the new virtual adapter. In reality Ethernet 2 and the new vEthernet are two aspects in Windows of the same hardware device.
The Device Manager hardware optimization options belong to the Ethernet 2 device. The Internet configuration options (IP address, DNS servers, 6-byte Ethernet ID, etc.) have been moved to the new vEthernet device.
Network Connections is one of the old Control Panel tools that go back to Windows 95. Today Microsoft is trying to get you to use the new Windows Settings panels, where Network Settings rather interestingly recombines the two Devices to simplify the view of end users:
Here the Internet setting have been combined with the hardware device type under the old physical device name of Ethernet 2.
If you choose to dedicate a physical network adapter to be used only by Hyper-V, there is no need for a virtual host adapter and any previous Internet configuration will simply be discarded.
The Virtual Switch Meme
VMware Workstation, Oracle VirtualBox, and Hyper-V all have the same network configuration problem and the same set of options. Other software combines a set of adapters on VMs, an optional virtual network adapter on the host system, and an optional physical network adapter into a named configuration object called a “Network”. Microsoft has chosen instead to call it a “Switch”.
The metaphor of connecting virtual adapters on virtual machines to ports on a virtual network switch is nice and simplifies creating diagrams, because you probably already have a switch image in your list of Visio diagram elements:
But calling this a Switch is not really helpful if you are trying to really understand how the thing really works.
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.
Therefore, the strategic way to design virtual networking is to let each system (Windows, Linux, …) on the host or in a VM just run their normal processing through TCP and IP to the point where they have an Ethernet packet. Then instead of using any hardware device, turn the packet over to Hyper-V for delivery on a named Switch/Network. The packet contains a destination 6-byte Ethernet ID and Hyper-V knows the 6-byte Ethernet IDs of every virtual Ethernet adapter on the host or VMs. If the destination is not one managed by Hyper-V and the Switch/Network has an associated physical network adapter, then send the packet out on the physical network.
The Hyper-V device drivers in a Linux VM, Windows VM, or Windows on the host simply hand packets off to Hyper-V, and Hyper-V also creates something in the Windows Kernel that talks to the device driver of any physical network adapter that has been assigned to it.
Configuring Hyper-V Virtual Switches
Every time it starts up, Hyper-V generates a new Switch called Default. VMs connect to it by default. In the host system, it is connected to a Gateway service that provides automatic configuration through DHCP to the VMs, a DNS service using the host operating system current name resolution, and the host operating system Routing tables to select the best current way to send data to external networks. You cannot meaningly configure of delete this service because it is recreated from scratch every time you restart Windows.
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 allows us to describe the process as simply and cleanly as possible without some confusion built into the Manager tool.
Create
To create a naked Switch with nothing attached to it, you provide a Name and, because Microsoft does not expect that most people want to create a switch with nothing, you have to explitly confirm that you want it to be of type Private:
PS C:\Windows\System32> new-vmswitch -Name Example -SwitchType Private Name SwitchType NetAdapterInterfaceDescription ---- ---------- ------------------------------ Example Private
A naked switch can be connected to virtual network adapters on VMs. VMs can use it to talk to each other.
Add just the Host
A switch with a host connection is identified by a SwitchType of Internal instead of Private.
You can create the switch with that SwitchType, or having previously create a naked Private switch you can change the type of the existing switch:
PS C:\Windows\System32> set-vmswitch -Name Example -SwitchType Internal PS C:\Windows\System32> get-netadapter Name InterfaceDescription ifIndex Status MacAddress LinkSpeed Ethernet Intel(R) Ethernet Connection (18) I219… 23 Disconnected C4-C6-E6-30-3F-37 0 bps vEthernet (Example) Hyper-V Virtual Ethernet Adapter #4 66 Up 00-15-5D-02-A0-04 10 Gbps ...
Windows now has a new virtual network adapter connected to the switch. Note the currently disconnected first adapter named “Ethernet” for the next example.
Create Switch with both a Physical Ethernet Adapter and a Host connection
There is a logical problem if you create an Internal Switch, use it for a while, and then decide to add a physical network adapter to it.
The existing physical adapter has Internet connection parameters associated with it (an IP address on the existing external physical network to which it was connected (say 192.168.3.*).
The existing host virtual adapter connected to the switch has connection parameters associated with it. Worse, the fact that it exists at all suggests that you configured an Internal network where all the adapters on all the VMs have internal IP addresses (say 192.168.10.*).
Adding this physical adapter to the switch physically bridges two networks with two different IP subnets. Now there is nothing wrong with that, and it could work, but Windows doesn’t know what to do with the IP address on the host virtual network adapter. So, it solves this problem in what may be the worst possible way by creating a second virtual host network adapter (as if your Device Manager was not bad enough already). Both end up connected to the Switch. The original virtual network adapter created when you made the switch Internal keeps its old IP address in 192.168.10.* while the new second virtual Ethernet adapter connected to the same switch gets the external IP address previously assigned to the physical network adapter in 192.168.3.*
That is probably not what you want. Start over.
Delete the old Internal switch and start over.
Create a new switch with the same name, but give it both the physical adapter and the option to allow the host Windows system (called the Management OS in this context) to use the new switch.
PS C:\Windows\System32> New-vmswitch -Name Example -NetAdapterName Ethernet -AllowManagementOS $true Name SwitchType NetAdapterInterfaceDescription Example External Intel(R) Ethernet Connection (18) I219-LM PS C:\Windows\System32> get-netadapter Name InterfaceDescription ifIndex Status MacAddress LinkSpeed Ethernet Intel(R) Ethernet Connection (18) I219… 23 Disconnected C4-C6-E6-30-3F-37 0 bps vEthernet (Example) Hyper-V Virtual Ethernet Adapter #4 32 Disconnected C4-C6-E6-30-3F-37 0 bps
You need to know the name of the physical netadapter (“Ethernet” from the previous example).
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.
It is useless because all it does it set the default choice among three radio buttons on the next form:
You give it a Name at the top and can change your mind and click any of the three radio buttons for Private, Internal, or External (where you then choose a physical network adapter from the list and click the Allow Management OS checkbox to create a host virtual network adapter with the Switch.
You can come back to this form and change the type of switch with the radio buttons, but you have the same IP subnet conflict problem changing from an existing Internal to External.
Network Adapters in the VM configuration
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.
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.
This is something like plugging a USB Ethernet adapter into a computer.
When you create a new Virtual Network Adapter you will be given a chance to connect it to any of the defined Virtual Switches or else to leave it unconnected for now:
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.