The Internet Stack
Every application program interacts with the Internet through a programming interface provided by the Operating System Kernel known as the Socket API originally defined by UC Berkeley in its BSD Unix system. A client program can specify one network adapter by its IP address or let the operating system choose the best available adapter. It specifies the other end (the server) by an IP address (determined by looking up the name in DNS) and the port number of a service (such as 443 for the Web https: protocol). A connection is established between the client and server through the internet. Each end then sends data by presenting varying length blocks of bytes which are treated as a continuous stream of bytes delivered to the other end.
The Socket API is presented to programs by the operating system Kernel. Within the Kernel there are steps in the processing of the data traditionally referred to as Layers.
TCP is responsible for ensuring that the data is received by the other end and recovering if some data is corrupted or lost somewhere in the Internet. It maintains a count of bytes sent from one end and a count of bytes successfully received at the other end. The sender must maintain a copy of bytes sent but not yet acknowledged (the “window” of data in transit) so that lost data can be retransmitted until it is successfully received. Data sent is preceded by a “TCP header” with the number assigned to the first byte of data being sent or acknowledged and the port number associated with the program that is the client or server at each end.
IP is responsible for routing data through the internet from the sending computer to the receiving computer. An IP Header containing the IP address of the sender and destination is placed in front of packets containing the TCP Header and program data.
Ethernet is responsible for sending the IP packet from a computer to the router/gateway device that connects each computer to the corporate or campus network or to the network of your Internet Service Provider. Except in special cases, the maximum size of an Ethernet packet is around 1500 bytes. Each LAN adapter has a 6-byte Ethernet ID number, and each packet on the network has an Ethernet Header with the 6-byte ID of the sending adapter and the destination adapter.
The original Ethernet hardware is no longer used, but today the Ethernet standard is emulated by adapters that connect to wires, fiber optic cables, cable TV, WiFi, Bluetooth, the 5G cellphone network, or to Starlink satellites. There are obviously vastly different types of equipment to connect to all these different types of transmission, but the operation to “send this 1500 byte Ethernet packet on the network” is universal and is, therefore, the way that all the different types of networks communicate with each other through gateway modem and router boxes.
Virtual Networks
A Virtual Machine behaves as if it were a computer. It runs an operating system and presents to that OS the appearance of one or more Ethernet network adapters. To simplify things, a VM only sees a simple wired LAN adapter, like the wired “RJ45” port built into every PC sold today.
In datacenters with specialized server hardware, there may be specialized network adapters that communicate directly with many virtual machines. In this case, the VM networks is provided by specialized hardware. However, when you run VMs on your own home or office computer, Windows has to somehow connect both the applications running on the native Windows system and the VMs running on Hyper-V to every type of network adapter that you could choose to plug into your desktop or laptop computer. This includes the LAN adapter on the motherboard, the WiFi card, adapter cards plugged into a PCIe slot, or external adapters connected by USB or Thunderbolt.
In the Kernel, communication from programs to every network adapter goes though device driver support providing the TCP layer process, then the IP layer processing, then the Ethernet layer processing. Once the Ethernet packet is formed, the next step can involve sending the data to a chip on the motherboard, an adapter card, or out the USB connector to hardware that connects to anything.
So, Hyper-V stops at the point where the Ethernet packet has been formed before things get complicated. The Ethernet packet is universal. In the simple case where a VM is talking to a program on the host Windows system, no hardware has to be involved. The Ethernet packet built by a Linux VM can be simply moved in memory to the Windows Kernel, and Ethernet packets built by Windows can be moved in memory to the Linux VM kernel.
Windows has code that turns the host Windows system in to a gateway device for the VMs. Hyper-V always creates a “Default” network to which VMs can be connected, and if that is the only network you define then the VMs can talk to the host computer or the Internet through the Windows host system without any further configuration. However, the Default network does not allow other computers to talk to the VMs.
VMs can be connected to a real LAN adapter so that they appear as real computers on the real network and can communicate with other devices on the network. To do this, an administrator on the Windows host has to select one or more LAN adapters that will either be shared between Windows and the VMs or will be dedicated to the VMs.
If a network adapter is dedicated to one or more VMs, then it is removed from the list of adapters that the Windows applications can see (although the administrator still sees it in the list of devices). Essentially, the Windows Kernel cuts off all of the layers above the Ethernet packet processing for that device. Windows does not provide the socket, TCP, or IP processing.
Meanwhile, in the VM most modern operating systems have a special network device driver that the OS uses when it discovers that it is running in a Hyper-V VM. This Hyper-V VM network adapter supports the socket, TCP, and IP layer processing and stops when the VM has created an Ethernet packet that is ready to be sent out.
Hyper-V provides a service (the “V-bus”) that allows the host Windows Kernel to exchange data with the VMs. Through this service, the Ethernet layer in any VM can send an Ethernet packet to the Windows Kernel, where it is pugged into the Ethernet layer of the real network adapter that was configured to support VM network access. Similarly, Ethernet packets received by the physical network adapter can be sent back to the Ethernet layer of the VM where they move up through the IP, then TCP, then socket layers and are received by the application program running on the VM.
If a physical network adapter on the host Windows system is to be shared between regular Windows applications and also VMs, then when that adapter is prepared by Hyper-V for use by the VMs it is split into two separate “devices”. As in the previous example, on “device” consists of the real adapter starting at the Ethernet packet layer and then proceeding down through the various hardware layers. A separate network adapter is created for use by the Windows applications. It provides the socket, TCP, and IP processing and stops at the Ethernet packet layer. Windows programs can send data through this device, but when the data reaches the Ethernet layer then the packets are transferred inside the Kernel from the “host Windows system network adapter with the top half of the network stack down to and stopping at the Ethernet layer” dummy network adapter to the “host Windows Kernel network adapter bottom half of the network stack starting with Ethernet and going down to the specific real hardware shared between the host system and the VMs” device.
Each VM supervisor (Hyper-V, VMWare, VirtualBox, …) does the same thing, but each has its own way of presenting the three connection options (the Default network where the VMs are isolated inside the host system, a dedicated LAN adapter connected to VMs but not to the host system, or a LAN adapter shared between host applications and VMs).
Hyper-V chooses to present these options through the metaphore of a Virtual Switch. When reading the Hyper-V documentation, it is important to know that Hyper-V doesn’t even try to duplicate the behavior of a real network switch, so you should not assume that this virtual switch behaves in any way like a real switch. It is just an attempt by Microsoft to present the available network configuration options for Virtual Machines while avoiding the real description of Layers of network processing that you have just read.
Hyper-V Virtual Switches
Two physical PCs can be connected to each other by running a simple Ethernet cable between the RJ45 LAN adapter jacks exposed by both machines. This “network” consists of just the two machine cannot be used to access the Internet or anything else.
To connect three or more devices, you need to connect them to a “network switch” device. You can buy them from Amazon or Newegg for (at time or writing) as little as $14. A switch allows every device connected to it to communicate with each other, and if the switch is connected directly or indirectly to a gateway device, they can access the Internet through it.
When you configure a VM in Hyper-V, you can assign it one or more virtual network adapters. Modern operating systems recognize the Hyper-V virtual network adapter as a specific supported device and they have drivers for it.
Hyper-V automatically creates the Default virtual switch. A VM Hyper-V virtual network adapter can be “connected” to the Default switch. Then any network traffic from the VM goes through gateway code in the Windows host system and can access the Internet. However, this gateway logic only supports client programs in the VM and makes them appear to be applications running on the host Windows system. The VMs are hidden from other computers. This is frequently exactly what you want.
Every Hyper-V virtual switch can be connected to any virtual network adapter on any VM. If that is all you do, then the virtual switch is something like buying a $15 physical switch from Amazon and connecting it to unused RJ45 plugs on physical computers you own that presumably get their internet access over WiFi. If the switch is not connected to any gateway, then the computers can use it to exchange data between themselves, but not for anything else.
There are then two things you can do to a Hyper-V virtual switch that make it more interesting. You can connect it to the host Windows application programs and you can connect it to a physical network adapter on the host computer.
This paper has already described both options, but in terms of how they are actually implemented inside the host Windows Kernel by truncating the device driver layers on the physical network device above the Ethernet level and by creating a second dummy network adapter device that has no hardware but supports the socket, TCP, and IP layers above the Ethernet packet layer.
Truncating the upper processing layers and attaching the Ethernet down to the hardware part of a physical Ethernet adapter to a Hyper-V switch changes it to an “External” Hyper-V switch. You can do this when you create the switch or at any time in the future. You can remove an Ethernet adapter from a switch, or you can change which adapter is connected to which switch at any time.
Similarly, at any time you can create a dummy host operating system network adapter that contains only the processing layers down to Ethernet and attach it to any Hyper-V virtual switch.
However
...
You cannot change the Default switch. It is what it is and you leave it alone.
...
You can only have one physical network adapter connected to a switch at any time. You can add an adapter to any switch that doesn’t have one, delete an adapter from any switch that has one, and change the adapter associated with any switch, but there is no provision for two adapters to be connected to the same switch and trying to accomplish this by connecting two switches to a VM with some sort of bridging software will not work. You can connect them to a VM with some router software, but then you are connecting two distinct networks.
...
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.
| Info |
|---|
Normally connect the first network adapter on a generic VM to the Default network and let it dynamically configure itself. If you need custom networking, add a second virtual network adapter to the 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.
...
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.
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:
...
Using the Hyper-V Manager or PowerShell scripts, an administrator connects a virtual network adapter configured on a VM to the Switch. The host Windows system can also get a virtual network adapter connected to the Switch, and optionally one physical network adapter on the host system can also be connected to the switch. Loosely speaking, Ethernet packets transmitted by any virtual adapter connected to the Switch, and packets received by the physical network adapter from an external network are examined by Hyper-V and based on the 6-byte Ethernet ID in the destination field of the packet, it is transferred to the appropriate virtual network adapter configured with that ID.
Physical Network Adapter Bridge
Through Hyper-V, the host Windows system can assign one physical network adapter to a Hyper-V Virtual Switch. VMs attached to the Switch appear to the external Ethernet network as individual real computers. They can be assigned IP addresses statically or dynamically (from the external DHCP server). The VMs can expose database services or Web applications to the external real computers.
Remember that through the Default network any client on a VM can access any external service that the host computer to access. The only reason to assign a physical adapter to Hyper-V is so that external clients can connect to servers on the VMs.
If you have an unused network adapter available, you can choose to dedicate it to a Hyper-V Switch. Then only the VMs will use it, and the host will continue to use other adapters.
However, you may have only one network adapter, and you may already be using it for all your internet access. You can only afford to share it with the VMs. It is already configured with your personal communication preferences (IP address, name servers, etc.) and you don’t want to have to redo all that.
Hyper-V has to operate inside the Windows Kernel using the existing rules for device drivers and network stacks. One device cannot be directly connected to two different networks. Hyper-V is already set up to create a virtual network adapter if the host operating system wants to talk to VMs through a custom Hyper-V switch.
The last piece of the puzzle is that Window has always had a relatively obscure option to connect two physical network adapters together so the Windows machine can be used as a bridge between two physical networks. This may go back 30 years to a time when network equipment was more expensive, but it hasn’t been removed even though it is almost never used.
At a high level, the way this works is:
Hyper-V creates a virtual network adapter in the Windows operating system and connects it to the Switch.
All the Ethernet and Internet communications configuration on the physical network adapter is moved from the physical adapter to the new virtual adapter. Any networking tables in Windows associated with the IP address or Ethernet ID or active sessions are changed to point to the new virtual adapter.
The physical adapter, no longer connected to anything, is set up to act as a bridge between the external network (whatever is on the other end of the RJ45 cable plugged into the adapter) and the Hyper-V “Virtual Switch” component (which itself is a kind of bridge between the host and VM adapters).
Windows does this reconfiguration as quickly as possible, but there is a warning that there may be a very short interruption of communication. When it is done, all the connections between host applications and external network services are still live.
If you look in Device Driver and Network Connections, you will now see the old physical network adapter and the new Hyper-V Virtual Network adapter. You may note that the physical network adapter no longer seems to have Internet access. This is because it is now only operating at the Ethernet packet level moving data between the external network and Hyper-V. Internet access now appears to be provided through the Virtual Network Adapter that connects you to the Virtual Switch and VMs. Once the physical adapter is owned by Hyper-V, the Virtual Switch is the way that the host Windows system accesses the external network.
...
Layers (abbreviated)
At this point anyone writing about networking is obligated to mention the 7 Layers of the OSI Networking Model. Now that I mentioned it, we can ignore the textbook stuff and just talk about how network stuff is done in the Windows Kernel.
An application calls some library of services to send a stream of bytes over a connection to some remote network endpoint known by its IP address or hostname and a port number.
Inside the Kernel part of the Windows networking code wraps the stream of data into a TCP “packet” associated with a port number destination. The TCP packet is then broken into one or more IP packets with the IP address of the destination. The IP packet is then broken into one or more 1500 byte Ethernet packets with a 6-byte Ethernet destination address of another device on the local network, which may be the final destination or else will be a gateway device that forwards the data to bigger networks and eventually the whole Internet.
This processing up to this point is universal. It doesn’t matter what you are doing (browsing the Web or backing up your disk files) and it doesn’t matter how the network connection is made (wired, Wi-Fi, or Bluetooth through a Intel, Realtek, or Broadcom chip that is on the motherboard, an adapter card, a USB port, or a Thunderbolt hub). The next step is a mess of possibilities. So, Hyper-V does not take the next step.
In every VM and on the host system, as soon as the data has been reduced to a bunch of Ethernet packets the Hyper-V virtual network adapter simply turns these packets over the Hyper-V system controlling the computer. Hyper-V can look at the 6-byte Ethernet ID destination in each packet. It knows every 6-byte Ethernet ID of every virtual adapter it created, and if it finds a match it can move the packet to the destination adapter in any VM or in the Windows host. If the destination is not known, but the Swtich is associated with a physical network adapter, then it can send the packets out on the external Ethernet network to have them delivered.
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 breaks the process down to a step by step procedure that explains the possibilities more clearly than using the GUI configuration panel.
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
| Code Block |
|---|
PS C:\Windows\System32> New-VMSwitch -Name Example -SwitchType Private |
A naked switch can then be connected to virtual network adapters on VMs. Once connected, the VMs can talk to each other, but not to the host or the Internet through this Switch.
Add the Host
Hyper-V provides communication from the host Windows system to the Switch, and therefore to the VMs connected to the switch, by creating a Hyper-V Virtual Network Adapter device in the host Windows 11 operating system.
If there was a command to create the host virtual network adapter, then you could execute it twice and get two of them. Hyper-V doesn’t want you to have two, so the adapter is created when you change the SwitchType from “Private” to “Internal” and is deleted if you then turn the SwitchType back from “Internal” to “Private”. You see the new virtual adapter in the list returned from “Get-Adapter”.
| Code Block |
|---|
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
... |
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. Frequently addresses are assigned to a physical network by a DHCP server on a gateway router supplied by your ISP. For the example, assume the physical Ethernet uses the 192.168.3.* subnet.
Adding the physical adapter to the internal Hyper-V network would “bridge” two different networks with two different subnets. This would work, but nothing could talk to a device on the other subnet.
| Info |
|---|
If you have an existing Internal Switch and absolutely want to add a physical network adapter to it knowing the consequences, first change it to SwitchType Private to get rid of the existing host virtual network adapter connected to the Switch. Then use Set-VMSwitch to add both the physical network adapter and a newly generated host virtual network adapter to the Switch (implicitly changing it to SwitchType External) so Hyper-V will get the bridging set up correctly between the physical device and the new virtual device in the Windows Kernel. |
Create a Switch with a Physical Network Adapter
The only operation with a sensible result is to attach the physical network adapter to a new Switch you create as part of a single operation.
| Code Block |
|---|
PS C:\Windows\System32> New-VMSwitch -Name HomeNet -NetAdapterName Ethernet -AllowManagementOS $true
Name SwitchType NetAdapterInterfaceDescription
HomeNet 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 (HomeNet) Hyper-V Virtual Ethernet Adapter #4 32 Disconnected C4-C6-E6-30-3F-37 0 bps |
If you have an existing Internal or Private network connected to VM adapters, you can either reconnect the VM adapters to the new Switch or create new virtual adapters on some of the VMs and connect them to the new Switch while also leaving the VM connected to the old network with the old subnet.
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, but you can always change that selection before you click the create button:
...
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.
...
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.
...
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.
...
VLANs
If you don’t know about VLANs or do not use them, ignore this.
...