Networking often gets overlooked during desktop VM setup, because it's so transparent, but if you want your virtual
desktops to stay connected, you can't forget the network.
Many administrators take networking for granted when it comes to physical desktops, so the network tends to escape notice when you deploy VMs on a desktop. But when you start running virtual desktops, you can't just leave your network as is. The default network settings in a VM aren't always the most useful, especially if you're working with more than one VM at a time or attempting to do more than just run a desktop-inside-a-desktop.
Let's explore some of the network options that are available for a virtualized environment, where they're most useful and why you might want to opt out of some virtual desktop network settings.
Network address translation
Network address translation (NAT) is one of the most common ways a VM operates within a network, and it works almost exactly the same way NAT works on a full-blown PC. The VM has a private-network address, with all requests forwarded to another host, and the outside world cannot reach the VM unless a port-forwarding mechanism is in place.
More on virtual desktop networking
Ensuring network connectivity for virtual desktops
How to prepare your network for VDI
Pros and cons of offline VDI
NAT is most useful for a virtual desktop network when you only have a limited number of addresses to be provisioned in a given subnet -- for instance, if the network you use has hard-assigned addresses rather than DHCP, and you need permission from an admin to explicitly assign an address to something. In such a case, NAT is handy because you can simply have the VM guest masquerade behind its host's IP.
Unfortunately, it also means the VM can't be used as a server unless you have port forwarding set up. It also means things like file sharing (for instance, Windows home groups) will be difficult unless it's between nothing but the VM and its attendant host. Note that some virtual desktop products, such as Oracle VM VirtualBox, have built-in port-forwarding functions to route traffic between the guest and host.
Best used for: Quick and dirty connections between a VM and a host. Not for advanced routing, unless you want to make that much more work for yourself.
The idea behind a bridged adapter is clever: A device driver is installed in the host's network stack that appears to the guest as a physical network connection, complete with its own network address. The end result is that the VM will appear to be plugged directly into the same network as the host and will have access to all the same network resources.
A bridged-adapter setup may be the best place to start with a VM, because it brings many advantages with relatively few disadvantages. The only drawback is that it requires you to install a driver on the host's network stack, but this generally doesn't create any discernible performance or stability issues.
Best used for: Most virtual desktop scenarios as a default, where VMs needs the same network access as the host.
Internal and host-only networking
Some virtual environments have a networking mode called internal networking that limits connectivity to only other VMs running on the same host. VMs talk to each other but cannot see any other network -- not even a network available from the host. This virtual desktop network setup may not seem useful, but it's a powerful way to isolate VMs from the outside world and expose them selectively.
A sub-variant of this is host-only networking. A host-only network lets VMs talk to each other and their attendant host, but not to the outside world.
Best used for: VMs that need connectivity with peer VMs and their host but not necessarily the rest of the network (for instance, network appliances being used in a local test scenario).
Other tips for VM networking
These network settings for virtual desktops don't have to be configured on a VM-by-VM basis; they can also be configured on an adapter-by-adapter basis. For instance, a single VM could have one adapter connected to its host via a bridged adapter connection and another adapter connected to other VMs on the same host via an internal network. This setup makes it possible to create network topologies that the VM application itself routes entirely. (That could also be accomplished via a host-only network.)
Also, keep in mind that no two VMs tend to be created for the same reason: You don't provision a workstation with the same memory as a server, and you don't give an experimental OS the same disk space as something that will be used for actual work. So, as you set up the network for your virtual desktops, determine what you're using them for and what kind of requirements come with them.