WSL Manager

"Running $N containers as separate WSL instances runs $N VMs and $N linux kernels."

But it doesn't, and this is what I'm disagreeing with.

If you instantiate WSL2, it launches a Linux VM. A single Linux VM. If you then run Docker with WSL2 integration (the default and hugely recommended), it uses that Linux VM as its VM as well, so you're still at 1 VM.

If you run 100 WSL2 instances, they will all use that single Linux VM, each doing namespacing for isolation with their own filesystems. If you run 100 Docker instances, they will all use that single Linux VM.

If you run 100 WSL instances, and 100 Docker instances (assuming, again, WSL2 integration which is the default), they will all be using that single Linux VM.

this is great and I have a feature request: A "refresh VM" feature that exports your home dir + packages into a new VM instance.

I've tried Optimize-VHD but renewing the VM this way frees up disk and speeds up the VM as well. None of the WSL settings for sparse disk / disk shrinking seem to work well.

Here's what I usually do

   $ tar -czf /mnt/c/Temp/home-backup.tgz $HOME
   $ apt list --installed > /mnt/c/Temp/packages.txt

delete the VM, create a new one, reverse the process.

   $ tar -cxf /mnt/c/Temp/home-backup.tgz -C $HOME
   $ apt update
   $ cat /mnt/c/Temp/packages.txt | xargs apt install

So there’s a good number of comments, I’ll try to address them:

- Yes, these issues persist with WSL2.

- WSL2 allows mounting between the system/subsystem, but there is considerable overhead.

- Using WSL for remote workspaces from the host is very much a mixed bag.

- Attempting to use WSL entirely with graphical applications has very limited/poor support.

- If you wish for VM acceleration, you have to use Hyper-V, not all toolchains work with Hyper-V and this heavily restricts the host machine.

- If you wish to do anything that crosses the subsystem and the host, line delimiters and platform detection are very error prone.

- If you accidentally misconfigure WSL2 (which is quite easy to do) the WSL userspace can have substantial access to the host files, often beyond what may be initially apparent.

- Of compatibility issues, non-standard socket implementations have caused a lot of incompatibilities with software for me.

Okay, are you guys using wrong terminology? Are you talking about a filesystem image as a "VM", because that would not be correct. A "Virtual HD" (VHD) is not a VM. Do you think a WSL2 distro instance is a "VM" because it's persistent? Did you know Docker containers can be persistent as well, people just choose as a best practice not to use it like that? Does that make them magical VMs?

WSL2 has a single VM running as the process vmmem (or vmmemWSL in the newest versions). This is the single Linux kernel that will be shared by every WSL2 instance. It will also be the instance that hosts Docker containers as well. I mean, I'm just echoing myself and apologies for the repetition, but this is just easily confirmed, utter factual truth.

A rootfs is not a VM. WSL2 and containers have different nuances about their filesystem and isolation (WSL2 instances is aware of other instances, for instance, as a design aspect, and WSL2 persists rootfs changes while docker as a best practices does not), but they're more alike than different. And they share little in common with something like VirtualBox or vmware, which actually isolate every such system as VMs.

Again, sigh, if you install 10 WSL2 "distros", you will have 10 rootfs overlays on your drive, and 10 persistence VHD files. When you run these the VM they all run under in the shared vmmem instance, which is the single utility Linux VM.

I've done a lot of in-depth WSL2 work, so I'm just aware of its particulars, but to cite some documentation-

https://learn.microsoft.com/en-us/windows/wsl/about

"WSL 2 uses virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM). Linux distributions run as isolated containers inside of the WSL 2 managed VM. Linux distributions running via WSL 2 will share the same network namespace, device tree (other than /dev/pts), CPU/Kernel/Memory/Swap, /init binary, but have their own PID namespace, Mount namespace, User namespace, Cgroup namespace, and init process."

(under "What is WSL2"?)

https://www.docker.com/blog/new-docker-desktop-wsl2-backend/

"WSL 2 runs all distros in the same utility VM, sharing the same Kernel."

If you run multiple distros take a look at the process manager and find the single vmmem or vmmemWSL (newer versions have the latter). That single instance is all of the instances, and all of the docker containers you might be running as well, each with namespace isolation (with WSL2 having intentional bridging between them for convenience). Visualise it by doing something intensive in any of them and seeing the single process react, because that's the single utility VM responsible for all of them. Further while starting up the first WSL2 instance or Docker container is expensive, requiring the initialisation of all of the resources for the utility VM and the memory to support it, subsequent iterations are much less expensive.