Every Virtual Machine runs an operating system that needs needs basic Internet access 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 a 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. that provides VMs with general network access without any configuration. In technical terms, Default provides each VM with network addresses and parameters through DHCP, resolves network names using the DNS configuration on the Windows host, provides a NAT gateway between the internal virtual network connected to the VMs and all the external networks connected to the host, and reuses the existing Windows ability to reconfigure networking as you move from home to office or from desk to meeting room and switch choosing from wireless, wired, 5G, or VPN.
| Info |
|---|
Normally connect the first network adapter on any Hyper-V 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 and connect it to a special network. |
The Default network is rebuilt every time the host computer reboots, and it chooses a block of network addresses at random. Therefore, the IP addresses assigned to each VM changes constantly. Default handles client programs on the VMs, but if you want to run a server program on a VM, you want a static IP address. To get that, simply create a second Hyper-V network, give each server VM a second virtual adapter on that second network, and assign static IP addresses to all the machines connected to it.
Additional virtual networks cost nothing. Having one network that handles all the outbound requests, and one that handles all the inbound requests might be extravagant if you had to buy real adapter cards and switches, but it is the simplest and easiest way to run Hyper-V.
Hyper-V Cannot Connect VMs to Real Hardware
Large datacenters have VM Host clusters that use specialized hardware designed specifically for VMs. Frequently a VM will be able to communicate directly to a shared disk controller or a shared network adapter. Hyper-V does not support such specialized hardware.,
Hyper-V can work on any computer that supports Windows. Disk and network adapters are connected to the host Windows Kernel using Windows device drivers and appear in the host Windows Device Manager. While earlier Windows VM support emulated adapter hardware on the VM, today there are device drivers for most operating systems (Windows, Linux, freeBSD, …) that are selected when a system boots up and discovers that it is running under Hyper-V (or VMware, VirtualBox, KVM, …). Instead of simulating hardware support for a SATA disk chip or an Intel I219-LM Ethernet chip, Hyper-V VM disk or network device drivers call a software interface provided by the Hyper-V host system. The operation is then transferred to Windows and run in the Windows Kernel, with results transferred back by Hyper-V to the VM.
There is at least something that Hyper-V “attaches” to the VM that appears to be a network adapter, but it normally exists only to tell the OS in the VM to use its Hyper-V drivers and ignore even the virtual hardware. We continue, however, to describe what is actually a set of software calls between applications and the OS Kernel and the device drivers, and Hyper-V in terms of the corresponding physical behavior of a real network connected to a real computer. For example, when Hyper-V “attaches” a virtual network adapter on a VM to a Hyper-V virtual network “switch”, the behavior that the VM sees is the same as if on a real computer someone plugged an Ethernet cable into a RJ45 network jack.
The host Windows operating system also wants to communicate with the VMs. Hyper-V can create a virtual network adapter in the host Windows system that appears to be on the same private network as the VMs. One special virtual network adapter is always created, but is hidden and not typically displayed to the user of the host operating system. This adapter is owned by a Gateway service running in the host Windows system that provides default basic network access from VMs though the existing Windows network access provided to applications on the host system.
Hyper-V can dedicate a physical network adapter to a VM, but the VM does not see the real adapter hardware. The adapter remains a host Windows device and appears in the Device Manager of the host system, but an examination of the device shows that it has been stripped of the drivers and services that allow the host system to use it. The device is dedicated to Hyper-V, which in turn “bridges” Ethernet packets between the physical device and the generic Hyper-V virtual network adapter attached to the VM. While the VM gets all the data from the device, the obscure hardware configuration options for the physical adapter remain visible only on the host Device Manager:
...
Generic Virtual Network Adapters
The virtual network adapters attached to the VM emulate a wired network.
A VM can access data through a Wi-Fi connection on the host operating system by using the Hyper-V network named “Default” which connects any VM to the network services that the host Windows system provides to application programs running on the host. This is something like your home router where computers can connect over a wired network to a box that provides network access, and the computers don’t know if that box is connected to Comcast TV cable, or Verizon 5G, or Starlink, or all three. With the Default network the VMs get Internet access, while you decide what network your laptop is really going to connect to.
You can define a second virtual network adapter on a VM, but it will look to the VM like a wired adapter. VM networks can be bridged to physical wired networks, but not to wireless networks that require some selection and authentication before they will talk to you.
The Virtual Switch Meme
All systems that mange virtual machines create both internal private networks and virtual networks with some kind of virtual bridge, router, or firewall to an external network of physical devices. In most cases, they configure a set of named “Networks” each having specific access.
Hyper-V decided to carry the “virtual xxx” meme one step further by describing each of its configured Networks as a “Virtual Switch”. It is true that whether at home or at work, every wired network connection from a computer plugs into a physical “network switch” device.
The main advantage of this meme is that you can find an image of a physical switch and include it in diagrams when you document a Hyper-V configuration:
...
The problem with this metaphor is that the Hyper-V “virtual switch” doesn’t behave like a physical switch. Specifically, when a switch fills up you can connect it by wire to a second switch, and all the devices on ether switch can talk to each other.
A Hyper-V Virtual Switch is infinitely large any will support as many connections as you want to define to as many VMs as you create, but you cannot connect two virtual switches to each other directly or indirectly. A real switch has to discover what is plugged into it, and when it doesn’t know what to do it transmits data to everything plugged into it to see if any device responds. A Hyper-V Virtual Switch has internal detailed knowledge of every VM connected to it, so Hyper-V cheats and uses that knowledge to route data to the correct VM.
If you want a VM to communicate to computers on another Virtual Switch, create a new virtual network adapter so it is on both switches at the same time. You can create VMs with router or firewall software to provide more controlled access between different groups of VMs, but that is something you create yourself, not a feature of Hyper-V.
Each virtual switch can be associated with one dedicated wired physical network adapter. This adapter has been disconnected from the Windows system and is used by Hyper-V to bridge traffic between the physical wired network plugged into the adapter and the VMs. Windows can continue to use such an adapter by creating a virtual network adapter in the host system that is connected to the virtual switch that has now acquired exclusive use of the physical adapter.
Physical Network Adapter Bridge
The Default network provides client programs running on VMs access to the local network, campus network, and Internet through the Gateway on the host Windows machine. Like physical Gateway devices, you can, with a bit of technical configuration, define a “port mapping” so that any well known port number on the Windows computer forwards requests connection request to a service program running on a VM.
An internal switch (with no physical adapter) provides the ability for programs running on VMs and the host Windows system to communicate as either clients or servers.
Therefore, the two remaining problems to solve by adding a physical network adapter to a Hyper-V virtual switch are:
A VM can appear to other devices on the physical network as a real computer. They can connect to services and programs running on the VM in the same way they would be able to connect to any physical computer.
Any VM can have a virtual adapter that behaves as if it were directly connected to that external network. It can discover devices by broadcasting a request to everything on the network. It can be discovered by requests broadcast by other devices on that network. It can use IPv6 as well as IPv4.
These are specialized but not necessarily technical problems. One example that does not require much technical sophistication occurs if you decide to put a Plex Media Server in a VM (the Multipass tool from Canonical will create one for you with a single command). Plex applications will try and connect to a local server, but it is easier for them to find a server connected to the physical network through a bridging adapter.
With older desktop computers connected to a wired network, there may have been only one adapter available. Today laptops typically use Wi-Fi, which leaves a wired network jack unused. Plug into a dock and you get another wired jack. For $30 you can get a USB wired adapter. Finding an unused wired network adapter is usually easy. You can connect two computers to each other by just plugging the two ends of an Ethernet cable into an unused wired network on each machine. Attach the corresponding network adapters on each machine to a Hyper-V virtual switch and the VMs on one computer can talk to the VMs on the other computer.
When the wired network adapter is an unused spare, you simply add new function. However, if Windows is using the wired adapter, Hyper-V has to go through a bit of reconfiguration to “share” the adapter between the host Windows system and the VMs. 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 connections, sessions, Internet configuration, tables, and buffers that were previously associated with the physical network adapter are moved to the new virtual network adapter. This strips the physical network adapter of everything it was doing with applications, TCP, and IP leaving only its raw Ethernet packet transmit and receive function.
An Ethernet bridging driver is created an attached to the physical network adapter and to the switch.
Now traffic coming in to the adapter from the external network goes to the bridge driver and is forwarded to the VMs or the host system. Traffic from the host system to a VM, or from a VM to the host system is routed directly to the destination by Hyper-V, which recognizes Ethernet destination IDs for all its virtual adapters. However, when any Ethernet packet has a destination that Hyper-V does not recognize as belonging to the host of a VM, then that packet is sent to the bridge and gets transmitted out the wire.
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.
...
Note: In this diagram the “(Bridge)” part of the third line is the name I give to the Hyper-V Virtual Switch I configure. It is also true that the physical adapter (Ethernet 2) is acting as a bridge, but if I had called the Switch “Fred” then the name on the third line would have been “vEthernet (Fred)”.
Layers (abbreviated)
At this point anyone writing about networking is obligated to mention the 7 Layers of the OSI Networking Model. There, I mentioned it and we can now ignore the textbook.
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). Since it is universal, Hyper-V can stop with the Ethernet packet and not worry about hardware. If there is a physical wired Ethernet hardware adapter, it will be handled by the existing Windows device driver and Hyper-V doesn’t have to know how that all works.
So, each VM virtual network adapter, and every host system virtual network adapter has buffers to hold, transmit, and receive 1500-byte Ethernet packets. Each packet has an Ethernet ID destination. Hyper-V knows the Ethernet IDs assigned to every virtual network adapter it created on the host and on any VM. If a packet has a destination that is another virtual adapter, the Hyper-V just has to move the data from the send buffer of one adapter to the receive buffer of another adapter using its access to the memory of all systems. If a packet destination is not something Hyper-V recognizes, it moves the packet to the transmit buffer of the bridge connected to the device driver of the physical adapter.
There are layers above and below, but Hyper-V interconnects the Ethernet layer components on all the VMs.
Configuring Hyper-V Virtual Switches
Every time your computer boots up, Hyper-V recreates and configures the Default Network/Switch. With admin authority you can damage its configuration, but then if you reboot it throws away whatever mess you made and rebuilds from scratch.
Virtual network adapters have no hardware configuration. The VM operating system can be configured with additional Ethernet IDs, IP addresses, DNS servers, and so on. Hyper-V doesn’t care what is going on in the VM.
The primary Hyper-V configuration steps are to create and name a Virtual Switch, connect it to virtual adapters on one or more VMs, and optionally to create a virtual network adapter on the host Windows system, and optionally bridge the switch to an external network through a physical wired network adapter.
Planning
The panels for configuring a Virtual Switch in the Hyper-V Manager and the admin PowerShell commands have a “SwitchType” selection that is obviously important but not well defined.
If you create a new Virtual Switch, it is not connected to any VMs. You could then associate it with a physical network adapter that is not connected to any network. Then you could build a network from scratch adding VMs, and hosts, and physical devices one at a time. This requires no planning.
However, if you connect the physical network adapter to an existing physical network, it will have devices with some already configured subnet addresses that are either statically configured on each device (and a pain to reconfigure) or vended by a DHCP service somewhere on the external network. Now when you add VMs to the switch, they will either get addresses assigned by the same DHCP service or will need to be given static IP addresses in the same subnet as the existing external devices.
Now flip the scenario. You have an existing internal Switch attached to a group of VMs. Either they have static IP addresses or one of the VMs is providing a DHCP service. You could add a physical network adapter, connect it to an empty physical wired switch, and then plug external devices into that switch one at a time. They would need to be statically configured on the existing VM subnet or else get addresses assigned from the DHCP server on the VM.
What you cannot do is take an existing physical network of devices with one set of IP subnet addresses and maybe a DHCP server and bridge it to a separate internal network of devices with a different subnet and maybe a second DHPC server. You could not successfully do that connecting two physical switches to each other, and you cannot do it successfully with Hyper-V.
You connect two subnets to each other through a router or a firewall. Hyper-V does not provide either service. You can create a VM with OPNsense or pfSense firewall software, but if you did that you would want to create a new Hyper-V virtual switch with just the physical network adapter and the OPNSense VM and give the VM a second virtual adapter connected to the existing internal network. Then configure the firewall to allow traffic between the networks.
Therefore, Hyper-V expects that when you create a virtual switch, you will either create it with an associated physical network adapter (an External switch type) or else create a switch that has only VMs (Private) or only VMs and the host operating system (Internal). You can always add or remove the host operating system from the switch (creating or deleting the virtual network adapter in the host Windows system). However, Hyper-V really doesn’t expect you to add a physical network adapter to an existing virtual switch.
There are ways to force this, but this produces bad results (especially two virtual network adapters in the host operating system connected to the same virtual switch). Don’t do this. Create a new External virtual switch with the physical adapter and then reconfigure the VMs to connect to the new External switch instead of the old internal switch. Decide if you have a problem with different internal and external subnets.
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
There are commands to add a virtual network adapter to a VM. There is no command that obviously adds a virtual network adapter to the host Windows system. You create a host virtual adapter as a side effect of changing the SwitchType from “Private” to “Internal”. You delete the adapter by changing the SwitchType 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.
Create a Switch with a Physical Network Adapter
A virtual switch associated with a physical network adapter has SwitchType “External” and to create it you have to designate which physical network adapter you are assigning to it. At the same time, you can add a virtual network adapter on the host Windows system with the AllowManagementOS option.
| 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 |
You can then connect virtual network adapters on VMs to the new empty switch you just created.
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. While you need to have decide this in advance, the problem is that you can change your mind in the next panel.
...
All the previous selection did was to set the default on the radio button that determines the SwitchType. You can change your mind here and select another radio button. As in the PowerShell commands above, if you choose to create an External switch, you need to select a physical network adapter from the pulldown list and can check the AllowManagementOS checkbox.
...
It is nice to have a pulldown list of network adapters, but it would be more helpful if the list did not include adapters that are already assigned to a different switch. If you make a mistake and select such an adapter, you can fill everything in, but when you click OK the attempt to create the switch will fail because the selected adapter is in use.
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 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.
...