Setting Up WSL2 on Windows: Virtualization Gotchas, CLI Control, and Resource Tuning
A practitioner guide to installing and managing WSL2 on Windows, tackling nested virtualization conflicts, hypervisor clashes, CLI lifecycle commands, and memory limits.
4 min read
On this page
Getting a proper Linux environment inside Windows used to mean running heavy desktop VMs in VMware or VirtualBox, eating half your host memory just to keep an idle GUI alive. WSL2 (Windows Subsystem for Linux 2) changes that by running a real Linux kernel inside a lightweight, stripped-down utility VM managed directly by Hyper-V.
Setting it up is usually a one-liner, until you hit virtualization conflicts, nested VM setups, or memory hogs. Here is the practitioner playbook for installing, managing, and troubleshooting WSL2.
1. Virtualization Prerequisites & Hypervisor Conflicts
Before touching WSL2, your hardware virtualization (VT-x on Intel, AMD-V on AMD) must be enabled in your UEFI/BIOS.
The Nested Virtualization & VBS Clash
If you are running Windows inside a lab hypervisor (like Proxmox or ESXi) or troubleshooting conflicts where third-party hypervisors (like VMware Workstation or VirtualBox) fight with Windows for CPU virtualization extensions, Virtualization-Based Security (VBS) and Credential Guard will often get in your way.
When Credential Guard or VBS locks hardware virtualization features:
- Press
Win + R, typegpedit.msc, and press Enter. - Navigate to:
Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard - Double-click Turn on Virtualization Based Security, set it to Disabled, and click Apply then OK.
If you need to completely disarm Hyper-V to hand hardware virtualization back to another hypervisor or clear a botched hypervisor state:
# Run in Administrator PowerShell
Remove-WindowsFeature Hyper-V
bcdedit /set hypervisorlaunchtype off
(Note: WSL2 requires the Microsoft Hyper-V architecture. If you ever disabled hypervisorlaunchtype, re-enable it with bcdedit /set hypervisorlaunchtype auto before launching WSL2).
2. Installing WSL2
On modern Windows 10 (Build 19041+) and Windows 11, installation is streamlined into a single command that enables required optional features (Virtual Machine Platform, WSL) and downloads the latest Linux kernel.
The Standard Install
Open an Administrator PowerShell prompt:
wsl --install
By default, this installs Ubuntu and sets WSL2 as the default architecture. Reboot when prompted.
Inbox vs. Store Package
Windows supports two distribution channels for WSL:
# Standard: Installs from the Microsoft Store (updated independently of OS builds)
wsl --install
# Inbox: Installs WSL as an in-box Windows component (updated via standard Windows Updates)
wsl --install --inbox
Unless you are running an air-gapped enterprise machine with Microsoft Store blocked, stick with the default Store-backed version. It receives kernel patches and networking features much faster.
3. Managing Distros and Environments
WSL provides a fast CLI to query, install, and swap distributions without touching installers.
Discovering & Installing Distributions
# List available distributions in the online catalog (short alias: wsl -l -o)
wsl --list --online
# Install a specific distro
wsl --install -d Debian
wsl --install -d Ubuntu-24.04
Inspecting Installed Distros & Architecture
# List installed distros, state, and WSL version (short alias: wsl -l -v)
wsl --list --verbose
Ensure your distributions run under version 2 (real kernel) rather than version 1 (translation layer):
# Ensure new distributions default to WSL2
wsl --set-default-version 2
# Convert an existing WSL1 distro to WSL2
wsl --set-version Ubuntu-22.04 2
# Set your primary distribution
wsl --set-default Ubuntu-24.04
4. Lifecycle & Process Control
WSL distros launch in seconds, but background daemons and container engines can keep the VM alive and chewing CPU in the background.
Stopping Individual Distros
If a daemon goes rogue or you want to free up resources from one specific environment:
# Stop a single running distro
wsl --terminate Ubuntu
Shutting Down the WSL Subsystem
When Docker, development servers, or tests are finished and you want to reclaim your host RAM immediately:
# Shuts down all running distros and kills the underlying WSL2 utility VM
wsl --shutdown
Clean Purge (Nuking a Distro)
When an environment is broken beyond repair and you want a clean slate:
# Completely deletes the distro and unregisters its rootfs VHDX disk
wsl --unregister Ubuntu-20.04
Warning: This instantly purges all files inside
/homeand the distro filesystem. Back up your dotfiles or code repositories first.
5. Essential Tuning: Taming the Vmmem Memory Hog
By default, WSL2 will dynamically allocate up to 50% of your total host RAM (or 8 GB, whichever is less, on older builds; up to 50% or more on Windows 11). If you compile code or run memory-heavy workloads, the Vmmem process can squeeze your Windows host.
Create a .wslconfig file in your Windows user profile folder (C:\Users\<YourUser>\.wslconfig):
[wsl2]
# Cap memory allocation to keep Windows responsive
memory=8GB
# Assign virtual processor cores
processors=4
# Limit swap space
swap=2GB
# Turn off localhost forwarding issues if running local test listeners
localhostForwarding=true
Apply the new limits by restarting the WSL subsystem:
wsl --shutdown
wsl