WSL2 Virtual Disk Storage: VHD, VHDX, Sparse VHDs, and Distro Backup

If you have been using WSL2 for a while and recently tried to back up your Linux distro — only to discover the ext4.vhdx file is nowhere to be found — you are not alone. This article explains what changed, why it changed, and what you need to know to protect your WSL2 environment correctly. It draws on Microsoft's official documentation, the WSL engineering team's release notes, community research, and hands-on testing.

---

1. Background: How WSL2 Stores Linux Filesystems

Windows Subsystem for Linux 2 (WSL2) fundamentally changed the architecture of WSL when it was released in 2020. Unlike WSL1, which translated Linux system calls into Windows equivalents, WSL2 runs a real Linux kernel inside a lightweight Hyper-V virtual machine. This architectural shift introduced a requirement for a dedicated virtual storage device for each Linux distribution.

Each WSL2 distribution gets its own Virtual Hard Disk file — specifically an ext4.vhdx file — which stores the entire Linux filesystem using the ext4 filesystem format. This is the same filesystem used natively on most Linux distributions and supports all Linux filesystem features including permissions, symlinks, and extended attributes.

Historically, this file was located at a predictable path on your Windows machine:

C:\Users\<YourUsername>\AppData\Local\Packages\
CanonicalGroupLimited.Ubuntu<version>_79rhkp1fndgsc\
LocalState\ext4.vhdx

This location remained consistent for several years and became the standard guidance in most WSL2 tutorials and documentation. However, as we will see, recent changes to WSL2 and the Microsoft Store distribution model have significantly altered this behavior.

---

2. Understanding Virtual Hard Disk Formats: VHD vs. VHDX

Before diving into the WSL2-specific changes, it is important to understand the two virtual hard disk formats Microsoft uses and why the distinction matters.

2.1 VHD: The Legacy Format

VHD (Virtual Hard Disk) is Microsoft's original virtual disk format, introduced alongside early versions of Hyper-V and Virtual PC. Key characteristics:

Attribute	Detail
Maximum size	2 TB
Performance	Adequate for its era but increasingly limited
Reliability	Lacks journal protection against power failures
Compatibility	Broad support across older tools and platforms
Status	Largely legacy; not used by WSL2

2.2 VHDX: The Modern Standard

VHDX was introduced with Windows Server 2012 and Hyper-V 3.0 as a complete redesign of the virtual disk format. WSL2 uses VHDX exclusively. Key improvements:

Attribute	Detail
Maximum size	64 TB
Performance	Significantly better I/O performance, especially for 4K workloads
Reliability	Journal-based metadata updates protect against data corruption during power failures
Alignment	Better logical sector alignment improves performance on modern hardware
Dynamic sizing	Supports both fixed-size and dynamically expanding configurations

WSL2 uses VHDX in its dynamically expanding configuration, which means the virtual disk file grows on your Windows filesystem as you install software and create files inside your Linux distribution — but it does not pre-allocate the full declared maximum size.

VHD vs. VHDX Comparison

Attribute	VHD	VHDX
Maximum size	2 TB	64 TB
Power failure protection	None	Journaled metadata
Dynamic sizing	Limited	Full support
WSL2 usage	No	Yes (ext4.vhdx)
Recommended for	Legacy systems	Modern workloads

---

3. The WSL2 Default Storage Allocation

When WSL2 creates a VHDX for a Linux distribution, it sets a maximum size limit that acts as a ceiling for how large the virtual disk can grow. This maximum has changed over time as Microsoft has updated WSL2:

WSL2 Version	Default Maximum VHD Size
Prior to 0.58.0 (early versions)	256 GB
0.58.0 to pre-2.5 era	512 GB
2.5 and above (current)	1 TB

It is important to understand what this maximum means in practice. From inside your Linux distribution, running df -h / will show the maximum allocated size as the total disk size. This can be misleading — it does not mean your ext4.vhdx file is actually that large on your Windows drive. It means the virtual disk can grow up to that limit.

# Output example from df -h /
Filesystem    Size   Used   Avail   Use%   Mounted on
/dev/sdd      1007G   50G    907G     6%   /

# This means:
# - 1007 GB is the maximum the VHD can grow to
# - 50 GB is what is actually stored
# - The physical ext4.vhdx is approximately 50 GB on your Windows drive

According to the official Microsoft documentation, WSL mounts a VHD that will expand in size as you use it, so your Linux distribution sees that it can grow to the allocated maximum size of 1 TB.

---

4. Sparse VHD: What It Is and Why Microsoft Introduced It

4.1 The Problem with Traditional Dynamic VHDXs

While WSL2's dynamic VHDX grows as you add data, it has a significant limitation: it does not shrink automatically when you delete data. If you install a large application, use it, then uninstall it, the VHDX file on your Windows drive retains its expanded size. Over time, this leads to virtual disk bloat — the physical file on your Windows drive becomes much larger than the actual data inside the Linux filesystem.

This is a well-documented frustration in the WSL2 community. Developers working with Docker images, npm packages, Conda environments, or AI models (such as those downloaded via Ollama) would frequently find their ext4.vhdx files growing to tens or even hundreds of gigabytes, with no automatic reclamation of freed space.

4.2 Microsoft's Solution: Sparse VHD

In September 2023, Microsoft introduced Sparse VHD support for WSL2 as part of a major update that also brought mirrored networking mode, DNS tunneling, and automatic memory reclamation.

A Sparse VHD (also called a sparse VHDX) is a virtual disk that uses the Windows NTFS sparse file capability. Instead of allocating contiguous disk space for the entire virtual disk, a sparse file uses a special allocation map that marks regions of the file as either containing real data or as "sparse" (empty/freed) regions. The filesystem reports these sparse regions without them physically occupying disk space.

In practical terms for WSL2:

• Traditional dynamic VHDX: Grows when you add data. Does NOT shrink when you delete data.
• Sparse VHDX: Grows when you add data. CAN shrink automatically when you delete data, using NTFS trim/discard operations.

4.3 How Sparse VHD Works in WSL2

The sparse VHD feature in WSL2 works through cooperation between the Linux filesystem inside the WSL2 VM and the Windows NTFS filesystem on the host. When files are deleted inside Linux, the ext4 filesystem issues TRIM/discard commands to the virtual block device. WSL2's virtualization layer translates these into NTFS sparse file operations, effectively returning the freed space to the Windows filesystem.

This mechanism relies on SSD TRIM support, which means there is an important limitation: sparse VHDX automatic shrinkage works best when the virtual disk file is stored on an SSD. On a traditional mechanical hard drive (HDD), the TRIM-based reclamation may not function as expected.

Another nuance: when examining the sparse VHDX file properties in Windows Explorer, the Size field will still show the peak allocation. To see the true physical footprint, you must check Size on disk in the file's Properties panel.

Traditional vs. Sparse VHDX

Characteristic	Traditional Dynamic VHDX	Sparse VHDX
Grows as data is added	Yes	Yes
Shrinks as data is deleted	No	Yes (with SSD TRIM)
Requires manual compaction	Yes	Reduced need
Works on HDDs	Yes	Limited (TRIM-dependent)
Size on disk vs. Size	Identical	Can differ significantly
Introduced in WSL2	Original release (2020)	September 2023

---

5. Configuring Sparse VHD

5.1 Enabling Sparse VHD for New Distros

To automatically configure new WSL2 distributions to use sparse VHDs, add the following to your .wslconfig file located at C:\Users\<YourUsername>\.wslconfig:

[experimental]
sparseVhd=true

With this setting enabled, any new WSL2 distribution you install will automatically use a sparse VHDX. Existing distributions are not automatically converted.

5.2 Enabling Sparse VHD for Existing Distros

For distributions already installed, you can convert them using the wsl --manage command:

# Convert an existing distro to sparse VHD
wsl --manage Ubuntu-24.04 --set-sparse true

# Revert if needed
wsl --manage Ubuntu-24.04 --set-sparse false

5.3 Manually Triggering Space Reclamation

Even with sparse VHD enabled, you may want to manually trigger a TRIM operation to immediately reclaim freed space. From inside your WSL2 distribution:

# Manually trigger TRIM to reclaim deleted space
sudo fstrim -v /

# Example output:
# /: 12.5 GiB (13421772800 bytes) trimmed

5.4 A Known Limitation: Optimize-VHD Incompatibility

Users who previously relied on the PowerShell Optimize-VHD cmdlet will encounter a breaking change with sparse VHDs:

# This WILL FAIL on a sparse VHDX
Optimize-VHD -Path .\ext4.vhdx -Mode Full

# Error:
# The requested operation could not be completed due to a virtual disk
# system limitation. Virtual hard disk files must be uncompressed and
# unencrypted and must not be sparse.

For sparse VHDs, use fstrim from inside Linux instead of Optimize-VHD from Windows. The two approaches are mutually exclusive for the same virtual disk.

---

6. The New WSL2 Storage Model: When the VHDX Disappears

This is perhaps the most practically confusing change for experienced WSL2 users.

6.1 The Traditional Storage Location

For WSL2 distributions installed through the legacy Microsoft Store or via the inbox Windows component, the ext4.vhdx has always resided in the predictable Packages folder path. You could navigate directly to it, check its size, and copy it as a rudimentary backup.

6.2 The New Store Installation Model

Starting with the WSL2 Store application (reaching 1.0.0 in November 2022), Microsoft changed how WSL2 manages its virtual disks. Distributions installed through the new model — including Ubuntu 24.04 and other recently published distros — no longer store their ext4.vhdx in the traditional AppData\Local\Packages\<DistroName>\LocalState\ path. Instead, the WSL service manages the virtual disk directly, abstracting it away from the standard Windows filesystem hierarchy.

Even a recursive search across the entire C: drive for *.vhdx will return no results for these newer distros. Inside WSL2, the distribution's root filesystem appears as a raw block device:

# Inside WSL2 Ubuntu-24.04 (new Store model)
$ mount | grep 'on / '
/dev/sdd on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)

# /dev/sdd is a raw block device, not a file path
# The VHDX is managed by the WSL service, not accessible as a file

6.3 Identifying Which Model Your Distro Uses

# Check all installed distros
wsl --list --verbose

# Check disk space and device path
wsl -d Ubuntu-24.04 -- df -h /

# Search for the VHDX (old-model distros will show here)
Get-ChildItem "C:\Users\$env:USERNAME\AppData\Local\Packages" `
  -Recurse -Filter "ext4.vhdx" -ErrorAction SilentlyContinue

If the search returns results, your distro uses the traditional model. If it returns nothing, your distro uses the new abstracted model — and wsl --export is your only backup option.

---

7. Backing Up Your WSL2 Distribution

Regardless of which storage model your distribution uses, the officially supported and most reliable method for backing up and restoring WSL2 distributions is the wsl --export and wsl --import command pair.

7.1 Why Not Just Copy the VHDX?

Directly copying the ext4.vhdx file has several problems:

• File locking: The VHDX is locked by the WSL service while the distribution is running.
• Not applicable to new model: For new Store-installed distros, there is no accessible VHDX file to copy.
• No Microsoft support: Direct VHDX copying is not a documented or supported backup method.
• Portability: A .tar export from wsl --export can be restored on any machine, any Windows version, without compatibility concerns.

7.2 Step-by-Step Backup with wsl --export

Step 1: List your installed distributions and confirm the name

wsl --list --verbose

Step 2: Shut down WSL completely before exporting

wsl --shutdown
Start-Sleep -Seconds 10

Step 3: Export the distribution to a .tar archive

# Basic export
wsl --export Ubuntu-24.04 "D:\WSLbackups\Ubuntu-24.04.tar"

# Recommended: Include a date stamp for versioning
wsl --export Ubuntu-24.04 "D:\WSLbackups\Ubuntu-24.04-$(Get-Date -Format 'yyyy-MM-dd').tar"

Step 4: Verify the export completed successfully

Get-Item "D:\WSLbackups\Ubuntu-24.04-*.tar" |
  Select-Object Name, @{N='Size(GB)';E={[math]::Round($_.Length/1GB,2)}}

7.3 Restoring from Backup with wsl --import

# Restore to a specific location
wsl --import Ubuntu-24.04 "C:\WSL\Ubuntu-24.04" "D:\WSLbackups\Ubuntu-24.04-2026-05-31.tar"

# Parameters:
# Arg 1: Name for the restored distro
# Arg 2: Installation location (where the VHDX will be created)
# Arg 3: Path to the .tar backup file

7.4 Understanding Socket Warnings During Export

A common source of confusion when running wsl --export are warning messages like:

bsdtar: ./tmp/server_abc123: pax format cannot archive sockets
bsdtar: ./tmp/SingletonSocket: pax format cannot archive sockets

These warnings are completely harmless. Unix socket files are special inter-process communication endpoints that only exist while their parent process is running. The pax archive format cannot store socket files, so it skips them and logs a warning. Your backup archive is valid and complete despite these warnings.

To eliminate these warnings entirely, ensure WSL is fully shut down before exporting (Step 2 above).

7.5 Troubleshooting: Export Fails with Resource Error

If the export fails with error code 0x800705aa (Insufficient system resources exist to complete the requested service), the most common cause is that the distribution contains significantly more data than expected. Investigate disk usage inside the distro before retrying:

# Check overall disk usage
wsl -d Ubuntu-24.04 -- df -h

# Find the largest directories
wsl -d Ubuntu-24.04 -- bash -c "du -sh /* 2>/dev/null | sort -rh | head -20"

Common bloating culprits to audit before exporting large distributions:
* AI Models: Check du -sh ~/.ollama/models
* Docker Assets: Check docker system df
* Package Caches: Check du -sh ~/.npm ~/.cache

---

8. Managing WSL2 VHD Size

8.1 Expanding the VHD Maximum

If your WSL2 distribution is approaching the 1 TB default maximum, you can expand it. With WSL 2.5 and later:

# Shut down first
wsl --shutdown

# Expand to 2 TB
wsl --manage Ubuntu-24.04 --resize 2TB

8.2 Checking Physical VHD Size

For traditional-model distros where the VHDX is visible on disk:

# Find and measure the VHDX
Get-ChildItem "C:\Users\$env:USERNAME\AppData\Local\Packages" `
  -Recurse -Filter "ext4.vhdx" -ErrorAction SilentlyContinue | `
  Select-Object FullName, @{N='Size(GB)';E={[math]::Round($_.Length/1GB,2)}}

---

9. Official References and Further Reading

• Microsoft Learn — How to manage WSL disk space — The primary official reference. Covers disk space checking, VHD expansion, VHD repair, and locating the VHDX file.
• Windows Command Line Blog — WSL September 2023 Update — The official announcement post for sparse VHD, mirrored networking, and autoMemoryReclaim.
• Microsoft Q&A — WSL2 sparse VHD behavior and Optimize-VHD incompatibility — Community documentation of the Optimize-VHD error and workarounds.
• MicrosoftDocs/WSL GitHub Repository — The source for the official WSL documentation, including disk-space.md.
• WSL GitHub Issues — Community reports and Microsoft engineering team responses on sparse VHD behavior, resource errors, and edge cases.

---

10. Conclusion

WSL2's virtual disk architecture has evolved significantly since its initial release. The introduction of sparse VHDs in September 2023 addressed a longstanding pain point around disk bloat, and the shift to an abstracted storage model for new Store-installed distributions represents a broader architectural maturation of WSL as a first-class platform.

Key takeaways:

• Always use wsl --export for backups — it is the only officially supported method and works regardless of which storage model your distro uses.
• Shut down WSL before exporting — this avoids socket warnings and ensures a consistent filesystem state.
• Enable sparse VHD — if you are on an SSD, enable sparseVhd in .wslconfig to benefit from automatic disk reclamation.
• Do not expect to find the VHDX — for new Store-installed distros, the virtual disk is abstracted by the WSL service and is not accessible as a standard file.
• Use fstrim, not Optimize-VHD — for sparse VHDs, run sudo fstrim -v / from inside Linux to manually trigger space reclamation.
• Investigate bloat before backing up — Docker images, AI models, and package caches can silently consume tens of gigabytes. Audit with du before exporting large distros.