WSL 2 is the second generation of the Windows Subsystem for Linux, a Windows feature that runs a genuine Linux kernel inside a lightweight, managed virtual machine so that unmodified Linux distributions and their tools run alongside Windows applications. Under the hood, it is a specialized form of hardware-assisted virtualization: the user sees a Linux shell that starts in seconds, while underneath a utility VM on the Hyper-V platform hosts the kernel and every installed distribution.
WSL 2 replaced the original design, now called WSL 1, which translated Linux system calls into Windows kernel calls. Running a real kernel brought full system call compatibility and much faster Linux file system performance, at the cost of a virtualization boundary between the two operating systems.
How the WSL 2 architecture works
When the first distribution starts, Windows boots a single utility virtual machine through the Virtual Machine Platform component. Inside it runs a Linux kernel built and serviced by Microsoft, updated through the WSL package rather than by the distribution. Each installed distribution runs as an isolated container within that one VM, sharing the kernel but keeping its own root file system.
Each distribution’s files live in an ext4 file system stored in a VHDX virtual disk on the Windows side. Windows drives appear inside Linux under /mnt/c and similar paths, served across the VM boundary by a file-sharing protocol based on 9P. In the other direction, Windows reaches Linux files through the \\wsl$ or \\wsl.localhost network path.
Integration features hide the boundary. Interoperability lets Linux shells launch Windows executables and vice versa, WSLg displays Linux graphical applications through a Wayland compositor, and GPU paravirtualization exposes the Windows graphics driver to Linux for compute workloads such as CUDA. Memory that Linux frees can be returned to Windows dynamically, so the VM does not hold a fixed allocation.
WSL 2 compared with WSL 1 and classic virtual machines
WSL 2 sits between the translation approach of WSL 1 and a conventional virtual machine. The comparison below shows why it became the default for new installations, and why WSL 1 still has niche uses.
| Aspect | WSL 1 | WSL 2 | Full virtual machine |
|---|---|---|---|
| Kernel | None, system call translation | Real Linux kernel | Any guest kernel |
| System call compatibility | Partial | Full | Full |
| Linux file performance | Slow | Near native | Near native |
| Windows file performance | Fast | Slower across 9P | Requires shared folders |
| Startup time | About one second | A few seconds | Tens of seconds or more |
| Resource management | Native processes | Dynamic, managed VM | Fixed allocation by default |
Compared with a hypervisor stack such as KVM with QEMU and libvirt on a Linux host, WSL 2 offers far less control: there is one kernel per Windows user, no choice of virtual hardware and limited networking options. Its strength is seamless integration with the Windows desktop rather than general-purpose virtualization.
Configuring WSL 2
WSL 2 is configured at two levels. The global file `.wslconfig` in the Windows user profile controls the shared virtual machine, while `/etc/wsl.conf` inside each distribution controls per-distribution behavior. Changes apply after wsl --shutdown stops the VM.
| Setting | File | Effect |
|---|---|---|
| memory | .wslconfig | Caps the VM memory, by default half of host RAM |
| processors | .wslconfig | Limits the number of virtual CPUs |
| networkingMode | .wslconfig | Chooses NAT or mirrored networking |
| swap | .wslconfig | Sets the size of the VM swap file |
| systemd | /etc/wsl.conf | Starts systemd as PID 1 in the distribution |
| automount | /etc/wsl.conf | Controls how Windows drives are mounted |
Daily management happens through the wsl command in Windows: wsl --install sets up the platform and a default distribution, wsl --list --verbose shows each distribution and its version, wsl --set-version converts between WSL 1 and WSL 2, and `wsl –export` and `–import` move distributions between machines as tar archives.
Networking and file placement choices
Two practical decisions determine most of the WSL 2 experience. The first is where project files live. Tools inside Linux run fastest on the ext4 disk, so a repository used mainly by Linux compilers and package managers belongs in the Linux home directory, not under /mnt/c.
| Situation | Recommended choice | Reason |
|---|---|---|
| Linux build tools on large repositories | Files in the ext4 disk | Avoids slow cross-boundary file access |
| Windows editor on Linux files | Remote editor integration | Editor backend runs inside Linux |
| Services reachable from the local network | Mirrored networking | Linux shares the host interfaces |
| Corporate VPN problems | Mirrored mode with DNS tunneling | Uses the Windows network stack |
| Simple local development | Default NAT mode | Localhost forwarding works automatically |
The second decision is the networking mode. In the default NAT mode, the VM has its own private address and Windows forwards localhost ports to it. Mirrored mode, available on recent Windows 11 builds, mirrors the host network interfaces into Linux, which improves compatibility with VPNs, IPv6 and inbound connections.
Limitations and common pitfalls
- Memory growth: the Linux page cache can make the VM appear to consume large amounts of RAM; setting a memory cap or enabling automatic memory reclamation helps.
- Growing virtual disks: the VHDX expands as data is written but does not shrink automatically when files are deleted.
- Hardware access: USB devices need explicit forwarding, and kernel modules beyond the shipped kernel require a custom kernel build.
- Not a security boundary for Windows: Linux processes can read and modify the user’s Windows files through the automatic mounts.
- Nested virtualization: running KVM inside WSL 2 depends on CPU support and Windows configuration, and it is slower than on bare metal.
These limits follow from the design goal. WSL 2 is optimized for developer workflows on a Windows workstation, not for hosting production Linux servers, which belong on a dedicated hypervisor or bare metal.
In simple terms
WSL 2 is like having a small Linux computer built into Windows. There is no second screen, no second keyboard and no reboot. A person opens a terminal window, and a real Linux system is ready within seconds. It runs the same tools found on Linux servers.
Behind the scenes, Windows runs a slimmed-down virtual machine and manages it automatically. It starts when needed and uses memory only while busy. Files and programs can pass between the two systems. Users get Linux where they need it and keep their familiar Windows desktop.
A practical example
A web development team works on company-issued Windows laptops, but its production servers run Ubuntu. Previously, scripts behaved differently on developer machines, and a shared Linux virtual machine was slow to start. The team moves to WSL 2 with Ubuntu, enables systemd in /etc/wsl.conf so that a local database runs as a normal service, and caps the VM at 8 GB of memory in .wslconfig on 16 GB laptops.
Repositories are cloned into the Linux home directory, where a full test suite that previously crawled over a Windows-mounted folder now runs several times faster. Developers edit code in a Windows editor connected to the Linux environment. The outcome is that build scripts behave the same as in production, and onboarding a new developer takes one installation command instead of a day of virtual machine setup.