Difference between WSL with GUI and Hyper-V Virtual Machine

It is becoming very popular to set up WSL2 with the user interface separately and then accessing it with xrdp/RDP.

How does it differ from creating a virtual machine in Hyper-V?

Let's start with a note that WSL2 is running in a virtual machine (whereas WSL1 did not). It makes use of some of the underlying features of Hyper-V, but it is not Hyper-V. However, since they use the same hypervisor, they can coexist happily, unlike some other VM platforms.

WSL2 is not, however, a virtual machine platform like Hyper-V where you can create your own machine configurations.

Now on to your main question -- What is the difference between accessing WSL2 with xrdp and creating a Hyper-V virtual machine? Note that most all of the following should also apply to the upcoming WSLg feature in Windows 11:

• Interop: WSL provides some great interoperability features with Windows, including:

  • The ability to run Windows executables from within the WSL/Linux environment, including stdin/stdout/stderr piping and redirection.
  • Automatically mounting Windows drives into each WSL instance
  • Automatically sharing the Linux filesystem in WSL with Windows through a network share.
  • As of the recent release of Windows 21H1, the ability to use the accelerated GPU compute features (e.g. CUDA Toolkit) on your Windows GPU.

  You can, of course, share files between a VM and Windows, but you need to set it up yourself. However, the other two features are, as far as I know, not easily replicated on a VM.

• A VM platform such as Hyper-V will give you the ability to add and configure virtual devices (e.g. USB, display, audio). With WSL, you pretty much need to work with those devices as they are already configured. For instance, WSL's init process (its PID 1) will automatically configure networking using a (hidden to you by default) Hyper-V virtual NIC. You can't add to or change this network easily.

  And, of course, there's no "screen" on WSL2. Access, as you mentioned, is through xrdp or an X server. That also means that there's no "console". Each instance of WSL that you launch is a PTS.

  There's not even the concept of "power on/off" in WSL2, so attempting a shutdown won't have any effect.

• That /init PID 1 is a pretty big difference as well. Because WSL sets up its Interop during init, it uses its own process. This means that Systemd is not, by default, the PID 1, and you can't use or expect systemctl or any related commands to work. There are hacky workarounds for this, but you are probably better getting used to the non-Systemd equivalents. For instance, instead of sudo systemctl start ssh, it's the older SysVInit-style sudo service ssh start.

  I don't have any idea of your skills and comfort level -- If you are comfortable with Linux already and can make the adjustments needed yourself when reading documentation that makes use of Systemd, then great. If not, then a VM may be a better option, at least initially while "learning".

WSL and Hyper-V (or VMware) are two different things.

WSL is a facility to permit running Linux Commands in Windows. The GUI interface also helps manage documents and things you may wish to do. But it is not a full fledged Virtual Machine and does not function like one.

Notably the WSL interface is owned by the WSL terminal and cannot be restarted or shut down separately.

Virtual Machines in Hyper-V or VMware are almost real machines. You can do most things in a Virtual Machine that you can do in a real machine. Documents, Apps, browsers and all.

Notably, some hardware features of the host are not available to a Virtual Machine, but then not to WSL either.

Here are a couple of screen shots that attempt to show how WSL GUI fits within a host machine environment.

.

.