Virtual Machines need to be connected to your network. Hyper-V creates virtual network adapters on its VMs. Most modern operating systems are ready to run in a Hyper-V VM and are distributed with device support for Hyper-V network adapters in the same way that they support Intel and Realtek hardware network adapters. The administrator has to configure each VM network adapter to a logical network connected to other VMs, the host Windows system, or the real network. Hyper-V presents this configuration through the metaphor of a “virtual network switch”. The user can then imagine connecting VMs to virtual switches in the same way that physical computers are connected to physical switches with an Ethernet cable. However, Hyper-V does not even try to duplicate the exact behavior of a real Ethernet switch and the panels that Hyper-V provides to configure networking can be confusing. This paper will instead describe how Hyper-V virtual networking really operates.
The first step is to quickly describe the way that all operating systems expose the Internet to programs and process requests from the application to the network adapter. Then we can describe the way that this is modified for virtual machines, how Hyper-V in particular implements networking, and what options are available for configuration.
The Internet Stack
Sockets are the programming inteface originally invented by Berkeley Unix, the first operating system to put Internet support into its Kernel. The application program calls a service to lookup a computer name in DNS and return an IP address corresponding to that name. Different services have well known “port” numbers. For example, “https://” requests to the Web use port number 443. A client then connects to the service using the combination of IP address and port number, and its operating system provides a random large port number and inserts its own IP address when creating the connection. To the program, a socket accepts and returns a stream of bytes. The program could send and receive one byte at a time, but that would be inefficient. It is up to the program to decide how many bytes to send in one operation, and when it reads data the system returns however many bytes have been received up to this point.
TCP is one of the basic internet protocols and is built into every operating system Kernel. TCP provides reliable (error corrected) streams of bytes between the client and server programs. It also views the data as a stream of bytes, but TCP has to break that stream up into packets of data that can be efficiently sent through the network. To allow error correction TCP retains a certain number of bytes (the “window”) of data until it receives an acknowledgement message from the other computer that all those bytes were received correctly. If data is lost or corrupted by the network, it can be retransmitted. Packets can arrive in a different order than they were sent, so TCP is responsible for rearranging the data as it is received.
TCP inserts control information into the packet that contains the port number of the sending and receiving programs and the logical starting byte number of this data in the overall stream.
IP generates packets that are small enough to be sent through the network. Since the packets will pass through the Internet individually, each packet must contain the IP address of the destination and sending computer. The destination can be any computer anywhere in the world.
Ethernet is a protocol to send data between a small number of computers over short distances. Ethernet moves data between two devices inside your home, or inside an office or other building. Each network adapter on each computer or device has a unique 6-byte Ethernet ID. Ethernet packets by default are limited to around 1500 bytes and contain the Ethernet ID of the destination and sender. Ethernet can be wired or wireless, and Ethernet protocols are extended over long distance on fiber optics and Cable TV although this use is no longer “local area”.
An operating system creates an Ethernet packet the same way no matter when type of network or adapter will be used to transmit it. However, the next step down is where the packet is given to an actual piece of hardware for transmission, and the alternatives available are enormous. The physical network hardware can be built into the motherboard, a plug-in adapter card, an external USB device, or on a Thunderbolt dock. It can use copper wires, fiber optics, cable TV, WiFi, bluetooth, 5G cellphone, or Starlink satellites. It can be limited to one room, or span thousands of miles.
So, Hyper-V makes the rational strategic decision to locate all its virtual networking logic between the universal Ethernet packet support in the Kernel but above the physical hardware support for any specific hardware adapter.
Hyper-V virtual networking is based on two components:
A simulated adapter is installed in each Virtual Machine and in the Host Windows system. This component receives packets built by the Ethernet layer of the Windows or Linux Kernel and behaves as if it were just another hardware adapter, except there is no hardware here. It will move the packet around in memory, and eventually deliver it to another component of the Windows 11 host Kernel or one the operating systems in one of the VMs. It also simulates “receiving data from the network” when a packet generated somewhere else is addressed to this system.
A Hyper-V generic network adapter manager that sits in the Windows 11 host operating system kernel and can be assigned to control any network adapter hardware driver plugging into Windows through the standard interface that all network drivers present to Windows. In this case, the adapter is detached from direct access by Windows applications and only talks to Hyper-V.
Hyper-V talks to the simulated adapters in the VMs and on the host computer, and to the generic network adapter manager on any adapter that have been assigned to Hyper-V management. It moves Ethernet packets between them. Sometimes the packet just moves between VMs in memory, and sometimes the packets go through hardware adapters to a real network.
This is configured though the metaphor of a virtual switch, but there is an important difference between the behavior of this virtual switch and a real network switch. A real switch knows nothing about the device connected to one of its ports until the device sends a packet and the switch can see the 6-byte Ethernet ID in the packet. When the switch gets a packet with a destination 6-byte Ethernet ID it has never seen, it has to “broadcast” the packet by sending a copy of it out every port to every device. Hyper-V, however, creates and configures the VMs and is part of the Windows 11 host kernel. It knows the configuration of all these systems before they send any data. So, Hyper-V can “cheat” and use the information it already has where a real switch would have to explore and discover its devices.
However, Hyper-V does not know what is out on any real network connected to a hardware network adapter that has been assigned to it. When it gets a packet with a 6-byte Ethernet ID destination that is not associated with any VM or the Windows host, and a hardware network adapter has been assigned to this “virtual switch”, then the destination must be a device out on the real network and packet is sent to the physical network.
What Hyper-V Doesn’t Do
In datacenters with specialized server hardware, there may be expensive network adapters on the VM host clusters that can present a direct hardware interface to many virtual machines. The server then creates a direct connection between a VM and the physical adapter. This means that the VM has to have specific hardware support for that adapter device.
Hyper-V on a Windows 11 PC supports only the standard inexpensive adapters available on all computers. It does not have the ability to pass through the hardware behavior of a physical network adapter to a VM.
It is possible to dedicate one network adapter to one VM so that even the host operating system doesn’t see it, but you still have to create a generic Hyper-V virtual adapter on the VM. You then connect that adapter to a Hyper-V virtual switch that has no other VMs and is not shared with the host operating system, but which is connected to the one physical network adapter. This adapter only communicates to that one VM, but the VM doesn’t see the read hardware type of the adapter, and any hardware configuration of adapter options needs to be done using the Device Manager of the host Windows 11 operating system instead of the VM system.
“Default” - Virtual Network without Configuration
When Hyper-V is installed, it creates a virtual switch called “Default”. It needs no configuration and you cannot change it.
When you create a new VM, it usually gets a virtual network adapter connected to “Default”.
The “Default” switch provides the same services to VMs that the router/gateway provides to devices on your home network or the company provides to computers connected to its network. There is a configuration service called “DHCP” that automatically configures the addresses and network parameters on each device.
In the case of the Default Hyper-V virtual switch, each VM that uses it is assigned internal addresses and networking parameters that allow them to communicate to the host Windows 11 system. On the host system, Hyper-V provides a Gateway function (like the Gateway device that connects your home to your Internet Service Provider). The Gateway allows VMs to talk to the internet using whatever networks the host computer uses for its own applications. The Gateway resolves DNS queries from the VMs using whatever DNS servers the host Windows system is currently using. The Gateway rewrites packets from the VMs so they appear to have come from its own applications, and routes the packets using the network connections and configuration that it uses for its own applications.
For example, if the host computer is currently using WiFi for its own network access, then traffic from the VMs automatically goes over WiFi. If you disconnect from WiFi and switch to wired Ethernet on the host, then the traffic from the VMs automatically switches at the same time. The VMs do not have to be configured, but at the same time they have no control over what is really going on. If the host is a laptop and you carry it to a library of coffee shop, then the VMs start to use whatever you connect to. Turn on a VPN and the VMs use it.
The Default network allows VMs to access the Internet to download and install new software and apply patches. It hides the VMs other computers. The VMs can use shared files and services on the host, but the Default networking does not make it easy for applications on the host to find services provided by the VMs.
Configured Hyper-V Virtual Switches
Default cannot be controlled. If you need the ability to assign addresses and configure networking on VMs, then you create your own named Hyper-V Virtual Switch. Remember, the “switch” here is just a name for a configuration that:
Defines a set of virtual network adapters on VMs that are connected to each other and can exchange data.
Optionally creates a simulated network adapter on the host Windows 11 system that can communicate to this specific set of VM virtual adapters.
Optionally attaches one real physical network adapter on the host computer that has been assigned to Hyper-V control and is not directly available for use by host applications.
Originally someone decided to create network types named External, Internal, and Private. This was a really bad decision because it confuses the real choices and screws up the configuration process. I have specifically chosen not to introduce these terms previously because they more confusing than helpful. However, now that we are discussing configuration, they will appear in the utilities and have to be at least mentioned.
Hyper-V does not provide any DNS or network address assignment service to the virtual network you create when you define your own named Switch. If you need DNS or DHCP, then you have to create a VM to provide it. Normally you will provide a static configuration on each VM and then you don’t need an automatic service.
There are restrictions on the way you use Hyper-V virtual switches:
You cannot change the Default switch. It is what it is, and you leave it alone.
A virtual network adapter on a VM is either unconnected or is connected to one Hyper-V virtual switch. At any time, you can use the Hyper-V Manager or PowerShell to disconnect the virtual adapter from one virtual switch and reconnect it to another named virtual switch. The VM sees the same behavior as a real computer would see if a real adapter was unplugged from one network, then plugged into another network.
A Hyper-V virtual switch can be associated with at most one real physical network adapter on the host computer. At any time, you can use Hyper-V manager or PowerShell to change the physical network adapter connected to the switch to a new or different physical network adapter. In the Hyper-V Virtual Switch Manager configuration panel, a switch associated with a physical adapter is of type External and then the adapter is chosen by a pulldown box that lists all the adapters on the host system:
Choose carefully. Ideally choose an adapter that is not currently connected to a network and is not already associated with a different Hyper-V switch. After the switch is defined, connect the adapter to a network cable.
The host operating system can have at most one simulated network adapter connected to a Hyper-V virtual switch. At any time, you can create or delete this simulated network adapter in the Hyper-V Virtual Switch Manager but here is where the External. Internal, and Private type is all messed up. When there is no physical network adapter connected to the switch, then it is a Radio button choice between a network type of Internal (with the host connection) and Private (no host connection). When there is an associated physical network adapter (an External network type) it is the check box labelled “allow management operating system to share this network adapter”. It would be better if they just got rid of External, Internal, Private and just had the pulldown box and the checkbox on every switch.
A physical network adapter associated with a Hyper-V virtual switch cannot be used directly by applications on the host operating system. It can be administered, and you can make hardware configuraton changes, but if an application needs to use the device then you must create a simulated host network adapter connected to that switch, and then the host applications can share the physical adapter with VMs also connected to the same switch.
If a physical network adapter is connected to a Hyper-V switch, it is at that time removed from host networking. You get a warning message that host networking may be disturbed during the transition. If that adapter is the only want for host applications to get to a particular service, then existing application sessions may be disconnected. If there is an alternate route, the connections should be automatically switched over. If a physical adapter is disconnected from a Hyper-V switch, then it will return to the host networking device pool.
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.