Isn't WSL2 just a VM?

Original Article ↗ Hacker News Discussion ↗

WSL2 Architecture: “Just a VM” but Specialized

  • Consensus: WSL2 is fundamentally a VM running on a subset of Hyper‑V.
  • Differences vs a “normal” Hyper‑V VM:
    • Single optimized Linux VM/kernel shared by all “distributions”; new distros are more like containers.
    • Minimal, fixed virtual hardware and a Microsoft‑built kernel yield very fast boot and low overhead.
    • Dynamic memory and tight host integration are emphasized, though dynamic memory also exists in Hyper‑V proper.

GPU, Graphics, and GUI Apps

  • WSL2 uses GPU partitioning (GPU‑P) and a DirectX→Mesa/DRI bridge, enabling hardware‑accelerated graphics and CUDA/AI workloads.
  • PCIe passthrough is officially only supported on Server; WSL2’s GPU‑P hides that complexity.
  • Some users find WSLg’s out‑of‑the‑box graphics disappointing (blurry windows, sizing issues, WebGPU and driver testing hard).
  • IDEs often prefer “remote dev” models, hinting the GUI experience still isn’t fully seamless.

Performance: Startup, Memory, Filesystems

  • Startup is described as “insanely fast” (1–2 seconds) due to no firmware phase and a trimmed kernel with few drivers and no broad hardware probing.
  • Heavy WSL2 use (especially Docker) benefits from 20–32GB+ RAM.
  • Linux‑side filesystem access inside the VHD is fast; accessing Windows files from WSL2 (and vice versa) can be very slow, especially for JS toolchains with many small files.
  • Workarounds: keep Node/npm trees inside the WSL2 filesystem; Dev Drive/ReFS helps somewhat but not dramatically, according to one test.

Integration vs Traditional VMs

  • Advantages over a generic VM:
    • Automatic localhost port forwarding to Windows.
    • Windows drives auto‑mounted under /mnt/* and Linux files exposed via \\wsl$.
    • Easy cross‑calling (e.g., running explorer.exe from Linux, mixing Windows tools with Unix pipes).
  • Critics argue similar workflows are possible with Docker or full VMs and dislike the “split brain” view of processes.

WSL1 vs WSL2 Trade‑offs

  • WSL1 used a syscall‑translation “pico process” model (Drawbridge heritage), giving:
    • Tight process/handle/pipe integration with Windows.
    • Great for CI scenarios that need Linux tools and Windows binaries in one process space.
    • But poor I/O performance and incomplete kernel API support.
  • WSL2 brings better Linux compatibility, GPU support, and faster Linux‑side I/O, but loses shared process namespace and some IPC tricks. Some CI users find WSL1 still superior for mixed Windows/Linux workflows.

Networking, Storage, and Security Quirks

  • Multiple WSL2 distros are containers in one VM/kernel; bridging can give distinct IPs, but by default they share a NATed VM.
  • VHDX disks tend to grow; reclaiming space requires TRIM, sparse VHD config, or manual compaction, with auto‑shrink considered unreliable.
  • One comment notes WSL can bypass Windows firewall rules by default; others report difficulty getting SSH working, and a GitHub discussion is referenced.

Alternatives, Distros, and Use Cases

  • Some prefer VMware/VirtualBox or full Linux with a Windows VM for features like snapshots, full USB passthrough, and richer graphics environments (e.g., KDE Wayland).
  • Others see WSL2 as an excellent daily‑driver dev environment on corporate Windows, especially for cloud/containers and CUDA.
  • Custom WSL images are supported; Oracle Linux and AlmaLinux are mentioned as good RHEL‑like options.