Running native Linux utilities on a Windows machine historically meant one of two compromises: configuring a clunky dual-boot setup or allocating massive amounts of system RAM to heavy Type-2 hypervisors like VirtualBox or VMware Workstation. While virtual machines remain essential for hostile malware sandboxing and isolated penetration testing networks, they introduce unnecessary overhead for day-to-day scripting, automation, package management, and software development.
Windows Subsystem for Linux 2 (WSL 2) redefines this workflow entirely. Instead of running an emulation translation layer (as WSL 1 did) or launching an isolated, full-GUI virtual machine, WSL 2 deploys a real, Microsoft-maintained Linux kernel inside a lightweight, highly optimized Type-1 Hyper-V utility VM. It boots in under two seconds, utilizes dynamic memory allocation, and features near-instant execution of native ELF64 binaries.
When paired directly with Visual Studio Code, WSL 2 provides a seamless, enterprise-grade development pipeline: write your source code inside Windows with smooth GPU acceleration, while executing, compiling, and debugging inside a pure, native Linux filesystem.
This guide delivers an end-to-end, technical walkthrough for deploying WSL 2 on Windows 10 and Windows 11, provisioning an Ubuntu LTS environment, configuring your security boundaries, and linking your runtime to VS Code.
01 Prerequisites & Hardware Virtualization
Before provisioning WSL 2, your host processor must have hardware virtualization enabled at the firmware (UEFI/BIOS) level, and your Windows operating system must meet minimum kernel build requirements.
Hardware Virtualization Verification
Press Ctrl + Shift + Esc to open Task Manager.
Click the Performance tab and select CPU.
Locate the Virtualization entry in the bottom-right metrics panel.
If it reads Enabled, your system is ready.
If it reads Disabled, reboot into your motherboard firmware interface (UEFI/BIOS) and enable Intel VT-x (Intel Virtualization Technology) or AMD-V / SVM Mode (Secure Virtual Machine).
Operating System Requirements
Windows 11: All builds natively support the single-command setup.
Windows 10: Requires Version 2004 (Build 19041) or higher. You can verify your version by running winver in the Windows Run dialogue (Win + R).
02 Installing WSL 2 via Single PowerShell Command
Gone are the days of manually checking five different Windows Feature checkboxes, downloading separate MSI kernel packages, and configuring manual BCD settings. Microsoft now handles kernel provisioning, hypervisor feature activation, and distribution installation through a single unified CLI utility.
Step-by-Step Installation
Press the Windows key, search for PowerShell, right-click, and select Run as Administrator.
Execute the following deployment command:
What Happens Behind the Scenes:
Enables the optional Virtual Machine Platform tier.
Enables the Windows Subsystem for Linux feature.
Downloads and installs the latest Microsoft Linux Kernel package.
Sets WSL 2 as the global default execution architecture.
Pulls and unpacks the latest Ubuntu LTS distribution image from the Microsoft repository.
Once the process finishes, reboot your physical PC to allow Windows to configure the Hyper-V hypervisor abstraction layer.
(Note: If you already have an older WSL 1 instance and simply want to migrate your environment without data loss, run the migration commands below):
03 Initializing Ubuntu & Root User Provisioning
After restarting, Windows automatically launches an Ubuntu terminal window to complete the final distribution decompression and user account initialization.
1. Create a Non-Root User
You will be prompted to enter a UNIX username and password:
(Note: Terminal input for passwords is blind; characters will not appear on the screen while typing).
This newly created user is automatically granted passwordless or sudoer elevation privileges, allowing you to run administrative commands safely without logging in as root directly.
2. Update the Core Repositories
The default Ubuntu image contains base packages that must be synchronized with upstream repositories. Run your first update sequence:
Install standard build essentials and networking utilities to prepare your environment for development and security tooling:
04 Connecting WSL 2 to Visual Studio Code
The true power of WSL 2 lies in its client-server integration with Visual Studio Code. Rather than running VS Code inside Linux via an emulated GUI or editing files across a slow network share, VS Code splits its execution engine:
The UI (Client): Runs natively on Windows, leveraging your local GPU, display scaling, and themes.
The Server (Backend): Runs directly inside the WSL 2 Linux kernel, executing your extensions, terminal sessions, linters, and debuggers natively.
Step-by-Step Integration:
Download and install Visual Studio Code on your Windows host OS (if not already installed).
Launch VS Code, click on the Extensions icon on the left panel (or press Ctrl + Shift + X).
Search for WSL (published officially by Microsoft) and click Install.
Now, open your Ubuntu WSL terminal, create a test directory, and launch VS Code directly from Bash:
The first time you execute "code .", WSL automatically downloads and launches the headless VS Code Server binary. Within seconds, a native Windows VS Code window appears with a blue indicator in the bottom-left corner reading WSL: Ubuntu. Any integrated terminal you open inside this VS Code window (Ctrl + ~) is a genuine Bash prompt executing inside Linux.
05 Architecture Comparison: WSL 1 vs WSL 2 vs Type-2 VMs
Understanding how WSL 2 handles system calls and resources helps you decide when to use it versus a traditional virtual machine like VirtualBox.
06 File System Performance: Linux vs 9P Windows Mounts
One of the most critical operational rules when working with WSL 2 is understanding cross-filesystem performance.
The 9P Protocol Bottleneck
WSL 2 exposes your Windows drive partitions under the /mnt/ directory:
C:\ is accessed at /mnt/c/
D:\ is accessed at /mnt/d/
While convenient, accessing files located on your Windows host from inside WSL 2 routes data through the 9P network protocol. When running operations that involve thousands of small files—such as git status, npm install, or recursive Python scans—this cross-OS bridge causes massive latency slowdowns (often up to 10x slower).
The Golden Rule for WSL 2 Speed:
Store your project repositories inside the native Linux filesystem: Always keep your scripts, source code, and virtual environments inside your Linux home directory:
~/projects/ or /home/yourusername/ (stored on a native ext4 VHDX).
Accessing Linux files from Windows: If you ever need to view your Linux files inside the native Windows File Explorer, do not search through hidden AppData folders. Simply open your Ubuntu terminal and run:
This immediately opens a clean Windows Explorer window routed through the secure \\wsl$\Ubuntu network share.
❓ Frequently Asked Questions (FAQ)
Does WSL 2 consume RAM continuously like VirtualBox?
No. Traditional virtual machines lock up a fixed block of RAM (e.g., reserving 8GB out of your 16GB immediately upon boot). WSL 2 uses a dynamic memory allocator that only pulls RAM when active processes demand it and returns memory to Windows when idle. If you ever need to restrict its maximum ceiling, you can easily create a .wslconfig file in your Windows user profile (C:\Users\\.wslconfig) and set memory=4GB.
Can I run graphical Linux applications (GUI) inside WSL 2?
Yes. Modern WSL 2 releases include WSLg (Windows Subsystem for Linux GUI) out of the box. You can install native Linux graphical applications (like Wireshark, GIMP, or Nautilus) via sudo apt install, launch them directly from the Bash terminal, and they will render seamlessly on your Windows desktop with full Wayland and audio support.
How do I completely shut down or reset WSL 2?
If you want to terminate all background Linux processes and free all cached memory back to Windows, open a Windows PowerShell window and execute:
To restart it, simply click your Ubuntu terminal shortcut or execute wsl in any command prompt.