...
Hyper-V Virtual Switches
Virtual Machines communicate over one or more simulated wired networks (VMs do not simulate WiFi). In the real world a wired Ethernet nework (whether at work or at home) is created from devices called switches. Ethernet adapters in a PC are connected to a switch by an Ethernet cable, and switches can be connected to each other to build a larger network. Hyper-V describes its virtual network in terms of virtual switches, but the terms “switch” or “network” are interchangeable.
Hyper-V creates one initial virtual switch/network called Default, and if you are using Windows Home Edition that is all you get. On Pro or Enterprise you can install the full Hyper-V function with a Manager tool and create your own virtual switches. All Hyper-V virtual switches are identical, so the reason for having more than one is to separate which VMs talk to which other VMs, or to control how IP addresses are assigned.
Each VM can have one or more virtual network adapter cards, each of which is connected to one switch. VMs attached to the same switch share an IP subnet and can communicate directly to each other.
The Windows host OS on your physical laptop or desktop computer can itself get one or more virtual network adapter cards connected to Hyper-V virtual switches, thus allowing it to talk to the VMs.
A virtual switch can also be associated with a single physical Ethernet adapter in the physical computer. When used this way, the adapter itself is not a communications endpoint. It has no IP address itself. Rather, it is a raw low level Ethernet connection between a virtual switch and some external physical network or device. This allows VMs to appear on a real network as if they were real computers.
In Powershell commands, there are independent operations to create a virtual switch, attach a VM to a virtual switch, create a virtual network adapter on the host system attached to a virtual switch, and attach a physical Ethernet adapter to a virtual switch. However, the Hyper-V Manager is user friendly and allows you to do several things at once. For example, you can create an External virtual switch associated with an Ethernet adapter that the host system is already using. In one operation, the Hyper-V Manager creates a new virtual switch, and a virtual Ethernet adapter on the host system, transfers all the existing IP configuration on the physical Ethernet adapter to the new host virtual adapter, and not attaches the physical adapter (now stripped of all its IP configuration) to the virtual switch. This is a request that users make frequently enough that it is convenient to be able to do it all in one request. However, the Hyper-V Manager definition of “types” of virtual switches as External, Internal, and Private are not actual mutually exclusive choices but rather names it gives to the most popular three ways of configuring the switch, host virtual adapter, and physical Ethernet adapter options.
The “It Just Works” Networks
Hyper-V automatically creates a single virtual switch named Default.
This provides a self configuring virtual network with all the options needed for most casual users. all devices connected to a normal switch can talk to each other as members of the same “local network”.
Hyper-V chooses to define its virtual networking by configuring named “virtual switches”. Virtual network adapters on the VMs (and optionally in the host Windows system) are configured to “connect” to a named virtual switch to form a virtual local network. Although Hyper-V chooses to call its network configuration a “virtual switch”, this is just a metaphor to describe which virtual adapters on which machines can talk to each other. There is no process simulating the behavior of real physical switches, and you cannot connect or even bridge one virtual switch to another in the same way you would connection a physical switch to another physical switch with a cable.
Each vendor of Ethernet adapters distributes a driver for their device. Microsoft provides drivers for Hyper-V virtual Ethernet adapters on Windows and Linux, and drivers exist for most other operating systems like freeBSD used in OpenSense and pfSense firewall VMs.
Standard operating system services convert application data to TCP packets which are then enclosed in IP packets which are then enclosed in Ethernet frames. All that work is the same no matter what Ethernet adapter is being used. The Ethernet frame is then turned over to the hardware vendor driver which sends the frame out through the adapter. The Hyper-V driver sends the frame over the virtual bus that connects the VMs to the Kernel of the host Windows system.
Hyper-V can create a network that is entirely virtual. VMs can use it to talk to each other, but there is no direct connection to any physical external network. One VM or the host Windows system can act as a “gateway” to the Internet by receiving data from the virtual network, rewrite it (NAT) so it looks like it was sent by an application on the gateway computer, and then forwarding the data out to the Internet. If there is network level malware scanning installed on the gateway system, it may provide protection for the downstream hosts.
Alternately, Hyper-V can create an “External” network that is associated with a single physical Ethernet device on the Host system. Ethernet packets sent by one Hyper-V virtual Ethernet adapter that are not addressed to another Hyper-V virtual Ethernet adapter on the same network virtual switch are sent out through the physical adapter attached to that virtual switch. The packets then go to whatever network the physical Ethernet adapter is connected to. Each virtual Ethernet adapter on each VM has its own Ethernet 6-byte ID value, so each VM appears to the external network as a real computer connected to the real network.
The Default Network
Hyper-V creates one initial virtual switch/network called Default. Microsoft got tired of end users screwing up their Hyper-V networking and calling for support, so if a VM is connected to the Default network and turns on automatic configuration of network parameters (DHCP), then the VM will get access to the Internet as long as the host computer has network access.
However, to create a network that the user cannot screw up, Default assigns itself new IP addresses every time your machine boots up. So machines on the Default network have no fixed IP address you can connect to. You can reference a VM by appending “.local” to the hostname. If you are sane, the hostname will also be the VMName so you don’t get confused, but you have to rename the machine during or after the OS is installed.
In detail
There is no configuration or administration of Default.
When the host system boots up, Default gets a “factory reset” and chooses a random subnet range of addresses.
There is a virtual Ethernet adapter on the host Windows system attached to Default and assigned the first IP address in the subnet range.
Default uses DHCP to assign new IP addresses to each virtual adapter on a VM that is attached to it. It also sets the host virtual adapter address as the gateway and DNS server address for VMs.
The host Windows system provides a gateway service using the NAT protocol. When a client program on a VM connects to an Internet service, it passes the request to the host Windows system. The NAT function changes the request so it appears to be coming from a program on the host physical computer, and then sends the data out in the same way it would send data for a local application program. It will use wired, or WiFi, or VPN for this data in exactly the same way as it sends data from Firefox or Outlook.
When a VM gets an IP address from DHCP, the host Windows system writes the VM hostname (with a dummy domain suffix of *.mshome.net) and IP address in the file C:\Windows\System32\drivers\etc\hosts.ics. This is treated as an extension of the normal “hosts” file on every Windows or Linux system. When Windows is looking for a computer name, it checks the hosts files first before going to a DNS server. Therefore, if there is a VM named “docker” then the host can communicate to it using the dummy name of “docker.mshome.net”.
The VMs also get a dummy DNS server from the host. When they ask for the IP address associated with a name, then host OS looks the name up using its own standard API. This checks the hosts files first, then makes a DNS request if the name is not in the file. Therefore, the VMs get the same DNS server the host Windows system provides and can find each other using vmname.mshome.net.
...