A Virtual Machine runs an operating system that needs to be able to download programs, packages, and updates. Hyper-V provides a simple Default network connection that allows this basic function without any configuration or planning.
You have to be able to login to your VM in the same way you would sit at a screen and keyboard connected to any physical PC. The Virtual Machine Connection application associated with Hyper-V provides this function even when the VM is not connected to any network. This program allows disks on the host to be shared with the VM on all Windows systems and on Linux systems configured to support it (including the Linux Ubuntu system you can download using Quick Create), but you still need a virtual network to update software on the VM.
You have to configure a Hyper-V network if any VM is going to host a program that acts as a network server, like a database or a Web application. You may create an entirely private virtual network that only connects VMs to each other and to the host computer, or you can share a host physical network adapter with VMs and allow external physical computers in your personal environment to connect to the service.
In a datacenter large, specialized host devices may contain specialize network adapters that allow the adapter to talk directly to the VM. This type of hardware is not available on laptop or desktop computers. Each small scale VM supervisor (Hyper-V, VMware Workstation, Oracle VirtualBox, Linux KVM) presents a distinct interface and model for solving a common set of problems using completely different configuration options.
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.