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, like every other VM supervisor, has built in support for a Default network configuration that allows every VM to access Internet services. If install a new Virtual Machine and specify no options, it will get the Default network that assigns network addresses, provides name lookup, and uses the host Windows 11 system as a gateway from which all VMs can access the same networks that your Windows applications use.
This means that there is no additional configuration to Hyper-V or VMs than what you are already doing on your computer to browse the Web and process Email. As you move from place to place and switch between Wi-Fi and wired networks, Hyper-V roams like all your other programs. Incidentally the Default network setup allows client programs on a Hyper-V virtual machine to access servers (shared files, databases, a Web server) running on the host Windows 11 system.
A Virtual Machine does not need networking to allow a client program to access a server on the same machine.
Hyper-V provides the “Virtual Machine Connection” program that runs on the host Windows system and presents to the user a simulation of a screen, keyboard, and mouse connected to any Virtual Machine. This works even if the VM has no network at all.
Therefore, a discussion of Hyper-V networking is necessary only if one Hyper-V virtual machine runs a server of some sort that needs to be accessed by client programs running on another VM, on the host system, or on an external computer on a physical network connected to the host computer.
If you do not 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 vendor, there are large specialized systems that create hundreds of virtual machines. Frequently they run specialized systems that partition the use of physical hardware such as disks and network adapters among virtual machines. To do this, they need specialized network adapters that behave as if one adapter is really dozens of separate adapters each of which can be assigned directly to a VM. The VM talks directly to the adapter and needs to have drivers that support that specialized hardware.
Even when there is no exotic network adapter, some other VM systems can dedicate a specific network adapter to the exclusive use of a single virtual machine. In this case the VM sees that actual hardware and must have driver support for that specific network adapter.
Hyper-V runs on any desktop or Laptop Windows 11 system. It works with all the devices that Windows already supports. You configure devices, including network adapters, using the same Windows Settings or Control Panel screens you have always used.
Specific adapter may have optional hardware features that you can set in Device Manager. Most people don’t ever look at them, and few people understand how they work. You can usually get along fine by ignoring them:
Because the physical network adapter is installed in Windows with a Windows driver, this type of optional configuration remains under the control of the host Windows system. In Hyper-V, the VM does not need a driver that matches the specific network hardware, but it does need one driver to support a generic Hyper-V virtual network adapter device that Hyper-V creates on the VM. Windows, Linux, and some other operating systems (freeBSD which is popular with network appliances) have Hyper-V network drivers.
Hyper-V does not have the ability to directly connect a network adapter to a Hyper-V VM and pass-through its specific hardware features.
Generic Virtual Network Adapters
Hyper-V creates a much simpler generic virtual network adapter on each VM. It can also create a dummy virtual network adapter in the host Windows 11 operating system. These virtual network adapters can be used to communicate between VMs, and between the host operating system and the VMs, and no real network hardware is required.
There are times when a VM needs to communicate with an external network as if it were a physical computer. It needs to appear on the network with its own 6-byte Ethernet “address” ID and its own IP address. Devices on the physical network can then talk to it as they would any other computer.
Windows can share a physical network adapter with Hyper-V and though it with the VMs. To enable network adapter sharing, Windows splits the physical adapter into two Windows Devices that show up separately in Device Manager and Network Connections.
The old Device with the name of the physical adapter remains in place, but it loses the subset of its configuration parameters that are specific to the Windows host machine.
A new Hyper-V Virtual Network Adapter is created in the host Windows 11 system to receive the subset of communication options that are removed from the physical adapter. These include the 6-byte Ethernet ID and the TCP/IP Internet communication parameters (IP address, gateway, DNS servers, name lookup suffix, etc).
When Hyper-V associates a virtual network adapter on a VM to that physical adapter, the VM will have its own Internet communications configuration. After all, Windows and Linux running the the VM have their own network configuration panels to set Ethernet ID, IP address, gateway, and name servers independently of the host system, and the whole purpose of sharing a physical adapter with VMs is so that they can appear on the network as their own standalone computer.
You can tell Hyper-V to dedicate a physical network adapter to the exclusive use of Hyper-V. When you enter this command, Hyper-V does not create the second device in the host Windows system. Since the host system will no longer use this adapter for any network communications, any previous Internet configuration on that adapter is simply be discarded.
The Virtual Switch Meme
Hyper-V has decided to pretend that the VMs are like real computers connected to a wired network switch. You configure and name the “Virtual Switch”, then configure a virtual wired network adapter on each VM (and optionally on the host Windows system) and by command “connect” the virtual adapter to the switch. Optionally, you can associate a physical network adapter on the host computer with the “switch”, which then means that the VMs connected to that virtual switch can share that adapter, and optionally the host can continue to use it as well.
If you know nothing at all about how a real wired network switch works, then you better off in this one case. The Hyper-V “Virtual Switch” does not really have the kind of software or behavior that someone who understands networking would expect of any physical device. If your understanding is limited to “plug a bunch of computers into the same switch and they can talk to each other”, then that is a pretty good description of all that the Hyper-V networking configuration actually provides.
“Default” - Virtual Network without Configuration
When Hyper-V is installed, it creates a virtual switch called “Default”. You cannot delete it and you cannot configure it.
When you create a new VM, it usually gets a single virtual network adapter connected to “Default”.
The Default network assigns a randomly generated IP address to each VM (using the DHCP protocol).
It allows a VM to access the Yale Network, Home Network, and Internet through a Gateway function provided by the host Windows operating system. When any application on any VM tries to access a network service, it communicates through the Default Network to the Gateway. The Gateway separately connects to that remote service or computer on behalf of the client on the VM. The Gateway is an application on the Windows host system and uses whatever networks the host is currently connected to (wired, wireless). If you can access google.com from your browser on the host computer, the Gateway connects to it the same way. This means that a VM will transparently migrate with your laptop as you move from room to room and plug into or disconnect from any single network interface.
This behavior is so useful that I recommend that you configure every VM to have one adapter on the Default network to seamlessly support all your casual (non-developer) networking requirements.
The question then becomes whether you need a second network connection and how do you intend to use it?
A Simple set of Layers
If you read any book or take any course, you will be taught a list of 7 network Layers. To understand VM networking, we can reduce this to four layers.
The Program Interface - You may enter commands that talk to the network. You will provide these commands with the name of a computer or service, perhaps a port number, perhaps an application name, and perhaps a file name. The exact details depend on the operating system and programming language. Four our purposes, this all takes place in the “user” part of the system where you choose programs and, if you are a developer, where you write your own programs.
The Internet Protocol Support - This code existing in the Operating System Kernel. The Internet is based on two protocols named TCP and IP. IP routes your data through the Internet from your computer through intermediate gateways to the service you are using (google.com, youtube.com, weather.gov, etc.). TCP makes tracks the stream of bytes to make sure they all arrive and are reassembled in the correct order.
Ethernet - All networks today use Ethernet protocol to talk to small numbers of computers within a small area. Ethernet can be Wired, Wi-Fi, or Bluetooth. You cell phone probably support all three versions of Ethernet. What has made Ethernet successful is that any machine can connect to any network at any time. Each Ethernet adapter has its own 6-byte ID. Each packet of data has the 6-byte ID of the sender and the adapter to which it is being sent and the packet is normally limited to no more than 1500 bytes. There are then protocols for sending a packet to everyone on the network searching for a specific machine or service.
Hardware - Ethernet packets can run over a wire or radio. The adapter can be on the motherboard, or connected to a USB port, or on a docking station. It can be made by Intel, or RealTek, or Broadcom. This layer is a mess of different devices all doing the same thing but each in its own specialized way.
Hyper-V makes the rational decision to locate all its virtual networking logic at the Ethernet layer. Every Ethernet packet is no more than 1500 bytes long with a source and a destination. Ethernet packets can already be transmitted over wires, Wi-Fi, or Bluetooth, so why not just add Hyper-V as an alternate way to move the packets from one VM to another, or between VMs and the host computer.
Because the network is virtual, it is easiest to simulate a wired network. Wi-Fi has a connection process with channels and system ids and passwords. Bluetooth has pairing. With a physical wired network, you just plug each end of a cable into a jack, which you can simulate with virtual machine by a command or clicking a button on a configuration utility.
When someone plugs a wire into a real network switch, the switch doesn’t know what is at the other end of the wire. It could be a single computer, or it could be another switch connected to a hundred computers. The switch has to figure this out over time.
Hyper-V can cheat. It knows all the VMs and their virtual adapters. As soon as you connect something, Hyper-V knows its 6-byte Ethernet ID, and its IP addresses, and anything else that could be useful. Since it does not need to discover anything, it doesn’t need the logic or behavior of a real switch. So, there is no actual switch in a Hyper-V Virtual Switch. It is just a metaphor to guide network configuration.
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.
There is a simple logic to all Hyper-V Virtual Switches, but it is obscured by a confusing utility and documentation that combines things that should be regarded as separate.
The Virtual Switch
The Switch has a name. Create a name that describes its intended purpose.
Unfortunately, the Hyper-V Manager GUI interface asks you to choose a “type of virtual switch” in order to create it. All switches are the same. At any time you can convert a Switch to External by connecting it to a Windows network adapter, and at any time you can make it Internal or Private by choosing to connect it to the host Windows 11 operating system or not. You can connect or disconnect it from anything at any time.
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:
Associate a Switch with a Physical Network Adapter and
Allow the Host Windows System to Connect to it
Any Virtual Switch can be exclusively associated with one physical network adapter on the host Windows system. You cannot attach two physical adapters to the same switch, and you cannot attach the same physical adapter to two switches.
When a Switch is associated with a physical adapter, then all of the VMs connected to that switch share that one adapter and can talk to whatever devices can be accessed through that adapter. If you know in advance that the Switch will always be associated with an adapter connected to a specific type of network, then you might name the Switch for that type of Network.
If you take the advice to always connect a VM to the Default Network and use it to connect to all public services on the Yale Network or Internet, then the only reason to have other adapters and switches is to have other types of small networks on which you have a special set of devices.
Having thought about this for a long time, the only clear suggestion I will make is to create a Switch associated with a physical wired Ethernet adapter that is connected one larger and more powerful machine (the “desktop” computer) which has more memory and disk storage than your laptop. While this desktop computer has its own connection to the Internet and may do other work on its own, you run a single Ethernet cable between your laptop and the desktop computer and use it to create a little private network that the two machines use to talk to each other. On each machine you create a Switch named Bridge that is associated with the Ethernet adapter connected to the other machine. Then VMs on one machine can talk to VMs on the other machine over the private Bridge.
There may be other uses for Switches and Adapters that arise from your own specific requirements. You could, for example, create one Switch called Yale that you use when your laptop is at Yale plugged into the Yale Network, and another Switch called Home that you use when your laptop is at home. As you move from work to home, you disconnect the Switch for one environment and connect the Switch for the other environment. That provides a way to manage VMs that should only run a Yale from others that should only run at home.
Separately, you can choose to connect the host Windows 11 system to a Switch by creating a Virtual Network Adapter in the real host Windows 11 system. Up to this point we have discussed virtual adapters on virtual machines, but this is a virtual adapter on your real laptop computer. It allows you to talk through the switch to your VMs.
It is very common that you start with a host operating system with one wired network adapter. You install Hyper-V and are about to create your first VM. You want to share your wired physical adapter with your VM. The way to do this is to create a Hyper-V Switch that is connected to the physical wired adapter, but which is also connected to the host operating system.
It is natural to think of a single operation to “share my wired adapter with Hyper-V VMs”. There is also a disruption in the host networking when you remove the physical adapter from the host system and attach it to the switch, then create a virtual adapter in the host operating system and attach it to the switch. More importantly, you may have configured network parameters for that adapter on the host (an IP address, network mask, gateway address, DNS server address, and other stuff that most people ignore but developers may carefully specify in advance). All this configuration is specific to the host Windows 11 operating system and is not something you share with the other VMS. So, what you want is for all that Internet configuration that is currently in the Windows configuration of the physical adapter to be moved from that now shared adapter and instead be used to configure the virtual network adapter that is being created to connect the Windows 11 host system to the Hyper-V virtual switch and through it to the now shared physical wired Ethernet adapter.
Removing the physical adapter from the host operating system and associating it with a Hyper-V switch is one configuration operation. Creating a new virtual adapter in the host system and attaching it to the switch is a separate operation. You could do them separately in either order, but then you would have to do all the manual reconfiguration over again. So, Hyper-V manager presents a GUI interface that combines the two operations, so the configuration moves automatically from the physical adapter to the virtual adapter when you share it, and if you decide to stop sharing it and return the physical adapter back to the exclusive use of the host Windows system the configuration moves back in the opposite direction.
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.