WSL 3.0.2 Pre-Release Adds vNUMA for Large VMs and Experimental Sparse VHDs

The important caveat comes first. This build is labeled Pre-release on Microsoft's WSL GitHub releases page, and WSL 3.0.1 still holds the "Latest" tag. Treat 3.0.2 as something to evaluate, not something to push across a fleet on a Tuesday.

What shipped, and when​

Maintainer OneBlue published the release on October 5 at 21:30, under signed commit 0dc1bc1. The two headline items appear in the changelog as "Enable experimental sparse VHD creation by Ben Hillis (@benhillis) in #41726" and "Enable automatic vNUMA for large WSL VMs by Ben Hillis (@benhillis) in #41741". A related cleanup, "Reuse EmptyObject for HCS NUMA configuration", also landed. It suggests the NUMA work runs through the Host Compute Service layer that WSL uses to set up its VM.

Some background: Microsoft's 3.0.1 release notes announced that WSL containers (WSLC) are generally available. Phoronix's Michael Larabel calls 3.0.2 the first update since that WSL3 milestone.

Summary: WSL 3.0.2 is a signed pre-release dated October 5, 2026. Its headline items are automatic vNUMA for large VMs and experimental sparse VHD creation.

vNUMA: WSL learns what a big server looks like​

According to Phoronix, the vNUMA change followed a bug report from an Intel engineer: WSL would not launch at all on a host with more than 256 threads. Phoronix says automatic vNUMA handling should now let WSL work properly on multi-socket servers.

Why does NUMA matter? On a multi-socket system, each processor has its own local memory. Reaching memory attached to another socket is slower. A virtual NUMA topology tells the guest kernel (here, WSL's Linux VM) how the hardware is actually laid out. The Linux scheduler and memory allocator can then keep work close to the memory it uses. Without that, a guest sees one huge flat block of CPUs and RAM. Past a certain size, as this bug showed, it may not boot at all. (This explanation is general virtualization knowledge, not something Microsoft's release notes spell out.)

Some boundaries apply:

• The 256-thread figure comes from Phoronix, not Microsoft. The release notes give no thread threshold, list no validated server models, and name no required Windows builds.
• Microsoft's changelog makes no performance claims. "It launches now" and "it scales well" are separate statements, and only the first has any support.
• This doesn't turn WSL into a server hypervisor. WSL is still a developer tool built on a lightweight utility VM. Hyper-V remains the platform for real server workloads.

Who benefits? Mostly people doing kernel builds, compiler work, AI toolchains or hardware validation on workstation-class or dual-socket machines who want a Linux shell without setting up a separate VM. It's a small group, but they're exactly the people who hit odd scaling bugs first.

Summary: WSL should now run on very large multi-socket hosts, where it reportedly failed to start before. Scaling limits and performance are undocumented.

Sparse VHD: the old storage complaint returns​

Phoronix describes the new experimental sparse VHD creation as disk space being used only for data that has actually been written. That targets one of WSL's oldest complaints: the distro's virtual disk grows and never gives space back. One WSL management guide sums it up this way: the file "grows dynamically as you use space, but it does not shrink when you delete files."

This isn't the first try. Back in 2023, XDA Developers reported that a WSL pre-release added sparseVhd, which let users configure their virtual hard disk so that it automatically shrinks over time. The road since has been bumpy:

• A GitHub issue against WSL 2.0.9 reported that during Docker container creation, CPU, RAM and SSD disk usage all hit 100% with sparse VHDs enabled.
• A later report on Windows 10 complained that the sparseVhd setting does not reclaim disk space in Windows 10.
• In June 2025, a user on WSL 2.5.8 got a warning that "Sparse VHD support is currently disabled due to potential data corruption." The suggested --allow-unsafe override then failed with an invalid-boolean error.

Those are user reports against older builds. They don't prove anything about 3.0.2's new creation path. But they explain why the word "experimental" in this release deserves real weight.

What the documentation currently says​

Microsoft's WSL configuration documentation lists sparseVhd under the [experimental] section of .wslconfig. It's a boolean that defaults to false, and setting it to true makes any newly created VHD sparse automatically. Microsoft describes that section as opt-in previews of features it aims to make default eventually.

Community guides describe two layers: the global .wslconfig switch for new distros, and per-distro conversion with wsl --manage <distro> --set-sparse true. One storage guide notes that with the config setting, any new WSL2 distribution you install will automatically use a sparse VHDX, while existing distributions are not automatically converted.

Here's the honest gap. Neither Microsoft's 3.0.2 changelog nor Phoronix says whether 3.0.2 changes how you turn this on. They also don't say whether the old safety block on conversion has been lifted. Until version-specific documentation appears, assume nothing beyond "sparse creation is enabled, experimentally."

If you want to test it​

A cautious approach, based on general practice rather than any official 3.0.2 procedure:

1. Back up first. Export the distro with wsl --export. Community guides recommend it because it works whichever storage model the distro uses.
2. Use a throwaway distro. Test sparse creation on a newly installed distro, not the one holding your only copy of a project.
3. Check your version with wsl --version, so you know you're actually on 3.0.2.
4. Apply config changes cleanly. Microsoft's docs say .wslconfig changes only apply after the WSL VM fully stops. wsl --shutdown forces that, but it stops every running distro.
5. Watch for the old symptoms: runaway disk I/O, space not being reclaimed, or corruption warnings. Report anything odd on the WSL GitHub issue tracker with logs.

One more quirk: one community script found that Optimize-VHD refuses to compact a disk that is already sparse. If manual compaction is part of your routine, a sparse disk changes that workflow.

Summary: Sparse VHD creation is back, labeled experimental. The feature has a history of performance, reclamation and corruption problems, so back up and test on disposable distros.

The rest of the changelog​

3.0.2 is more than its two headliners. Other items from Microsoft's release notes:

• Networking: a fix for IPv4 forwarding when both IPv4 and IPv6 ports are listening, a fallback gateway when no IPv4 gateway exists in consommé networking mode, and a fix so the consommé loopback adapter doesn't fail when IPv6 is disabled.
• Security hardening: the DACL now only allows access to the user when virtual disks are created, and there's a fix for a race condition and potential use-after-free on system distro and init port access. The install logger now also refuses to write if the log file is a reparse point or directory.
• A reverted mitigation: the RedirectionGuard process mitigation added in 2.9.13 has been rolled back. The notes don't say why.
• WSLC containers: fixed event timestamps, container health notifications in wslc events, a new --format json option for that command, and Docker die/stop events now recorded the same way.
• Developer tooling: kernel headers and perf are now exposed to distributions, which helps anyone profiling inside WSL.
• Systemd compatibility: WSL again re-creates its binfmt_misc entry if systemd-binfmt overrides it. That entry is what lets Windows executables launch from Linux.

The bottom line​

WSL 3.0.2 is a small release with two signals. The vNUMA work shows Microsoft fixing WSL for hardware far beyond a typical developer laptop. The sparse VHD work shows it trying again to fix the disk bloat every long-time WSL user knows.

Neither feature is finished. The build is a pre-release, the vNUMA scaling limits are undocumented, and sparse VHDs have let users down before. Anyone running a 256-plus-thread workstation should try it. Everyone else can wait for the release to be promoted, unless a disposable test distro and a fresh backup are already ready to go.