Does WSL2 run Linux in a virtual machine or alongside the Windows kernel?

Question

I've always wanted a Linux terminal in Windows and was fulfilled by WSL 1. But it was painfully slow as it was (I guess) a Hyper-V-managed virtual machine. With WSL 2, it's way faster relatively but I cannot understand how Microsoft made it so.

Did they improve Hyper-V or did they stop using a virtual machine and create some magic to run the Linux kernel in parallel?

Solution

From the article About WSL 2 of Microsoft Docs:

Brief overview of the WSL 2 architecture

WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience. A traditional VM experience can be slow to boot up, is isolated, consumes lots of resources, and requires your time to manage it. WSL 2 does not have these attributes. It will still give the remarkable benefits of WSL 1: High levels of integration between Windows and Linux, extremely fast boot times, small resource footprint, and best of all will require no VM configuration or management. While WSL 2 does use a VM, it will be managed and run behind the scenes leaving you with the same user experience as WSL 1.

As how we can see in the following articles (and discussions below them) WLS 2 uses Hyper-V feature:

• Microsoft devBlogs: WSL 2 is now available in Windows Insiders
• Thomas Maurer blog: Install WSL 2 on Windows 10

Comments

[Admin]

It's still virtual, but WSL2 uses a linux (4.9) kernel instead of changing the calls to windows APIs and handling it that way.

[Admin]

so I guess WSL 1 was just a hoax(no linux kernel).

[Admin]

@Sachin WSL 1 runs ELF binaries on Windows by translating Linux system calls to Windows system calls, which makes it exactly what its name describes, "Windows Subsystem for Linux"

[Admin]

WSL 1 was not virtual @guiverc

[Admin]

@Sachin.Verma: What do you mean by "hoax"? WSL 1 was an implementation of the Linux kernel API and ABI, just like the Linux kernel is an implementation of the Linux kernel API and ABI. In fact, that is how most Linux compatibility layers work, e.g. the ones on FreeBSD, HP-UX, AIX, Solaris, etc. are also mostly independent re-implementations of the Linux kernel ABI and API instead of ports of the Linux kernel. It also works the other way around: all the compatibility layers for commercial Unices on Linux were independent re-implementations of their APIs and ABIs.

[Admin]

WinE also works the same way. It implements the Windows API and ABI, instead of porting Windows to run on Linux (which wouldn't be legally possible).

[Admin]

@Sachin.Verma Who told you WSL 1 had a Linux kernel?

[Admin]

Actually the other way around. WSL1 didn't use a VM but WSL2 does.

[LatinSuD]

From what i've read so far: it will be isolated, it will consume additional resources, it will have a dedicated virtual disk.

[Evan Carroll]

I gotta say I would like more information on why theirs is "lightweight" and in which way it's less "isolated" and consumes less resources... Sounds like marketing wank.

[pa4080]

Hello, @EvanCarroll. I'm totally agree it sounds like marketing wank. But WSL is really lightweight than a traditional virtual machine, where we need to install and boot the entire OS. WSL can dirctly access Windows' storage devices via /mnt/c, /mnt/d, etc. And can operate over the Windows' file system. Also we can run some Linux commands from CMD or .bat files and (vice versa) some .exe files from WSL's console. And finally it defensively uses less resources, just type ps -aux within WSL and within some native Linux distribution and count the running processes.

[Evan Carroll]

@pa4080 a couple of things, first while you can bind mount files from windows to linux, it's so slow it's not a good idea: read the Docker docs. That's such a bad idea they clearly own it: "Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid docker run -v /mnt/c/users:/users (where /mnt/c is mounted from Windows)." AFAIK, it's no better than using a bind bound in any other virtual machine. And all of your FS events don't work and many of the calls are emulated.

[Evan Carroll]

Second, AFAIK, there is nothing on a Windows VM that makes their kernel take fewer processes than any other Linux kernel/light distro. Let's assume you have one container. You have all the processes and tasks in Windows, then you have all the processes and services to bootstrap Linux (mainly the kernel and an init system) (none of which is needed if running Linux on the metal), then you have the overhead of the container which is at best the same and at worst will require re-architecting because of slow i/o and no gpu access and other handicaps.