KomuraSoft LLC
Contact
Menu

The Depths of Windows Virtualization (Part 3) — Virtual Machines That Boot in Seconds: Why WSL2, Windows Sandbox, and Containers Are So Light

· · Windows, Virtualization, WSL2, Windows Sandbox, Containers, Hyper-V

When you create a Windows VM in Hyper-V Manager, it takes tens of seconds to start and monopolises several gigabytes of memory. Yet on the same PC, typing wsl returns a Linux shell within a few seconds, and Windows Sandbox opens a disposable desktop in a few seconds as well.1

Both rest on the same Windows hypervisor (Part 1, “Where Is Your Windows Actually Running?”). In Part 2 we saw that this foundation can create isolation stronger than the kernel. So why is one heavy and the other light?

The question the final instalment of the series answers is just one.

Full VMs are heavy — so why are WSL2 and Windows Sandbox so light?

Intended readers are developers and operators who use WSL2, Windows Sandbox, and Windows containers for development and validation, and want to understand their lightness and their constraints from the mechanisms up. Prerequisites are Windows 10/11; walking through the Windows Sandbox section requires a Pro, Enterprise, or Education edition (Home and Windows Server do not have this feature). Background knowledge is the notion of partitions from Part 1. The difficulty is intermediate.

1. The Bottom Line First

A lightweight VM keeps the isolation line (a dedicated kernel and a hypervisor boundary) and lightens the “copy of a complete guest OS”. Sandbox shares the host’s Windows itself; WSL2 replaces the guest with a small, purpose-built Linux; and in both cases memory is not a fixed reservation but is lent and borrowed dynamically with the host.

The source of a full VM’s weight is not isolation itself but duplication. Another OS image on disk, another OS’s worth of pages in RAM, and another full boot every time you start. Lightweight VMs cut that duplication with two policies: “share what is safe to share” (Sandbox) and “if you cannot share it, rebuild it small” (WSL2).

Three kinds of sharing that support lightweight VMsThe OS image a full VM used to duplicate is cut by sharing in Sandbox and by shrinking in WSL2; memory that is a fixed allocation by default (dynamic memory is the exception) becomes dynamic lending and borrowing with the host; startup is replaced by a light kernel and a minimal setup; only the isolation boundary remainsreplaced byreplaced byreplaced byFull VM: duplicationDisk: OS image copyMemory or startup?Memory: fixed defaultStartup: full bootShare（Sandbox）or shrink（WSL2）Dynamic host lendingLight kernel + min.

Figure 1: The skeleton of the answer to “the same hypervisor, yet light” is that they stopped duplicating, not that they stopped isolating.

Below we look at WSL2, Windows Sandbox, and containers in that order, and at which kind of duplication each of them cuts.

2. What a Full VM Is Carrying

As a baseline for comparison, here is what a traditional VM carries.

  • An independent OS image. It holds every file of the guest OS inside a virtual disk. Even if the host has the same Windows, it does not share it.
  • Coarse memory allocation. A traditional VM’s default is to allocate host memory at a static size. Mechanisms such as Hyper-V Dynamic Memory can grow and shrink the allocation within a configured range, but the means of adjusting to changes in demand are limited.2
  • A general-purpose full boot. Firmware, the boot loader, and the set of services start in the same sequence as on a physical machine.
The three loads a full VM carriesA full VM carries an independent OS image, memory allocation that is static by default, and a general-purpose full boot, and those show up as costs in disk, RAM, and startup timeFull VMIndependent OS imageMemory or boot?Static memory defaultGeneral-purpose bootExtra disk for a copyHolds unused RAM tooTakes tens of seconds

Figure 2: The breakdown of a full VM’s cost is paid not for isolation but for generality and duplication.

These are not defects; they are the price of the generality that “you can put anything in the guest”. For a use such as running an old Linux next to Windows Server, that generality is the value. But for a use such as “I want to run the same (or a predetermined) OS as the host, right now, for development or validation”, most of it is wasted baggage. Lightweight VMs put that baggage down by narrowing the purpose.

3. WSL2 — A Utility VM with a Purpose-Built Kernel

3.1. Structure: A Managed VM and the Distributions Inside It

WSL2 is a mechanism that runs a genuine Linux kernel inside a lightweight utility VM.3 There are three points.

  • The kernel is genuine, but it is a specialised product. It is a Linux kernel Microsoft builds from the Stable branch, already tuned in size and performance for WSL2. On the current standard, Microsoft Store–distributed WSL, the kernel is updated together with the WSL package itself and applied with wsl --update (on the older in-box distribution it came through Windows Update).4 Because it is a genuine kernel, system-call compatibility is complete, and tools such as Docker run as they are.
  • The VM is behind the scenes. Creating, starting, and stopping the VM is managed by WSL; the user just opens a shell. There is no VM-settings screen and no felt wait for a boot.4
  • A distribution is a container inside the VM. Distributions such as Ubuntu and Debian run as isolated containers inside one managed VM. They share the network namespace and the kernel, while namespaces such as PID, mount, and user are separated.3
WSL2 architectureA host Windows and a lightweight utility VM sit side by side on the hypervisor; a Microsoft-built Linux kernel runs inside the VM; and each distribution runs as an isolated container inside thatInterop (commands, files, network)HypervisorHost WindowsLightweight utility VMLinux kernel (Microsoft build; updated with wsl --update)Ubuntu (container)Debian (container)

Figure 3: The answer to “is WSL2 a VM?” is “yes, but a managed, behind-the-scenes VM”, and even if you install several distributions there is still one VM.

The moment you type wsl, the backside looks like this.

From running the wsl command to a shell returning in a few secondsIf the utility VM is not running when wsl is executed, the lightweight VM and Linux kernel start; if it is already running they are reused; and a shell returns in the distribution's containerNoYesRun wslIs the utility VM already running?Start the lightweight VM and Linux kernel (a few seconds)Reuse the VM that is already runningA shell returns inside the container

Figure 4: The wait is only a minimal VM start, and this is where putting down the baggage of a full boot shows up.

3.2. File I/O: Which Side You Put It On Makes It a Different Thing

The topic that always comes up in talk of WSL2 performance is where you put the files.

  • Operations on files on the Linux side (the ext4 virtual disk) are fast. That is because the Linux kernel talks to its own file system directly, and speed-ups of up to 20x versus WSL1 for tarball extraction, and 2–5x for git clone and npm install, have been reported.4
  • Operations on files on the Windows side (/mnt/c and the like) become slow because they go through file sharing that crosses an OS boundary. Cross-OS file-system performance is the one major item where WSL2 is worse than WSL1.4

So the rule is: “put project files on the same OS side as the tools that operate on them”.4 A repository you handle with Linux build tools goes on the Linux side; a solution you build in Visual Studio goes on the Windows side.

The fork in WSL2 file I/O pathsAccess to the Linux-side ext4 virtual disk is direct from the Linux kernel and therefore fast; access to Windows-side files goes through file sharing that crosses an OS boundary and is therefore slowLinux side (home, etc.)Windows side (/mnt/c, etc.)File operations inside WSL2Which side is the file on?Direct I/O to the ext4 virtual diskVia sharing that crosses an OS boundaryFast (examples of up to 20x vs. WSL1)Tends to be slowFix: put the file on the OS that uses it

Figure 5: What is slow is the path, not WSL2, so changing where you put the files often makes the performance problem disappear.

3.3. Memory: It Grows, It Shrinks, but It Doesn’t Always Give Everything Back

WSL2’s memory usage (you see it as the vmmem process in Task Manager) is not a fixed reservation; it grows and shrinks with use. Memory that processes have released is automatically returned to Windows under the pageReporting setting, which is enabled by default.5 Pages held as file cache used to not return to Windows until the VM exited.4 In current WSL, the experimental .wslconfig setting autoMemoryReclaim (the default is dropCache) reclaims the cache automatically as well.5 In environments where this setting is disabled, or on older WSL, a long session’s cache can remain until the VM exits and can pressure host memory.

How WSL2 memory grows, shrinks, and is returnedDemand growth inside WSL2 raises the VM's memory usage; process-released pages are returned to Windows under pageReporting, which is enabled by default; file cache is reclaimed automatically by autoMemoryReclaim by default; but on a disabled setting or older WSL it remains until the VM exits, and wsl --shutdown returns everythingProcess released (when pageReporting is on)Held as file cacheMemory demand grows inside WSL2vmmem usage growsHas that page been released?Automatically returned to WindowsautoMemoryReclaim reclaims it automatically (default)On a disabled setting or older WSL, it remains until the VM exitswsl --shutdown returns everything

Figure 6: What looks like “it only ever grew” is mainly the cache (and, when pageReporting is off, process-released pages as well), so know the return path before you decide it is a leak.

If you want an explicit upper limit, %UserProfile%\.wslconfig can control the VM’s overall memory, CPU count, and swap.5

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

After changing the settings, restart the VM with wsl --shutdown for them to take effect. This dynamic allocation — “the upper limit is a setting, the actual usage follows demand” — is taken even further in the next topic, Windows Sandbox.

4. Windows Sandbox — Reusing the Host’s Windows

4.1. Dynamic Base Image: A Complete Windows in 500 MB

Windows Sandbox is a disposable Windows desktop isolated by the hypervisor. Close it and everything disappears; the next time, it starts in a few seconds from a clean state.1

The first puzzle is the disk. It can boot a complete Windows, yet Sandbox’s base image is only about 500 MB after installation, and 30 MB compressed at distribution time.2 The secret is the dynamic base image.

  • Most OS files are immutable, so the host’s copies can be shared as they are.
  • The small number of mutable files cannot be shared, so a clean copy of them is kept inside the base image.
  • At startup, the host’s immutable files plus the local copies of the mutable files are combined to assemble a complete Windows image.2

In other words, Sandbox neither downloads nor stores a copy of Windows; it reuses the Windows already installed on the host to start.

How a dynamic base image is assembledImmutable OS files from the host Windows are shared; only mutable files are held as a clean copy in the base image; and the two are combined to assemble Sandbox's complete Windows imageShared as-isKeep a clean copyThe host's complete WindowsImmutable OS files (the majority)Mutable OS files (a minority)Sandbox boot imageBoots as a complete WindowsOnly about 500 MB needs to be stored

Figure 7: The form of giving up disk duplication is not “own another Windows” but “assemble it from the host’s Windows”.

That composition is what makes the following lifecycle possible. What is discarded is the local state inside the Sandbox. If you have mapped a writable folder from the host in the .wsb configuration file, changes there remain on the host.6

The Windows Sandbox lifecycleStarting prepares a clean Windows in a few seconds; after app validation or experiments you close it and all state inside the Sandbox is discarded so the next time also starts clean; but changes to a host folder mapped as writable remainNext startStart (a few seconds)A clean WindowsApp validation or experimentsCloseDiscard all state inside the SandboxChanges in a mapped writable folder remain on the host

Figure 8: Being able to return to clean every time is because the mutable part is a disposable copy, and discarding it is part of the design.

4.2. Direct Map: The Same ntdll.dll Is the Same Physical Page

Not only disk but RAM is shared as well. Because Sandbox runs the same OS image as the host, a technique called “direct map” is used so that, for OS binaries, it uses the same physical memory pages as the host. When ntdll.dll is loaded into memory inside the Sandbox, it points at the same physical page as the same binary already loaded on the host. Without exposing the host’s secrets to danger, it achieves a much smaller memory footprint than a traditional VM.2

“Share the same physical page among several users” — that is the same idea as DLL sharing through section objects, which we followed in Part 3 of the memory series (“Section Objects and Copy-on-Write”). That mechanism was sharing between processes; Sandbox does it across a VM boundary.

Physical-page sharing through direct mapAn app on the host and an app inside the Sandbox share the same physical memory page for OS binaries such as ntdll, reducing memory usageAn app on the hostHost-side virtual addressAn app inside the SandboxSandbox-side virtual addressThe same physical page (OS binaries such as ntdll.dll)No need to duplicate the OS's worth of RAM

Figure 9: Direct map is the idea of page sharing that has been used between processes, applied across a VM boundary.

4.3. Lending and Borrowing Memory: More Like a Process Than a VM

Against the static memory allocation of a traditional VM, the container technology that Sandbox sits on decides resource allocation dynamically in cooperation with the host. If the host runs short of memory, it can reclaim memory from the container the same way it reclaims it from an ordinary process.2 Hyper-V Dynamic Memory also grows and shrinks a VM’s allocation within a configured range, but Sandbox goes further: the difference is that it lends and borrows on the same field as the host’s memory management.

Memory cooperation between the host and SandboxA traditional VM's default is a static-size exclusive allocation with limited means of adjustment; Sandbox becomes a reclamation target in response to host memory pressure and lends and borrows memory on the same field as ordinary processesHost memory pressure risesWhere do we reclaim from?Ordinary processes' Working SetsThe Sandbox's (container's) usageFree memory is securedA traditional VM has limited means of adjustment

Figure 10: In the lending and borrowing of memory, Sandbox stands on the process side rather than the VM side, and offers memory up when the host is in trouble.

In Part 1 we said “a VM’s performance also depends on the host side”, but with lightweight VMs we take one more step: the allocation of memory itself is a joint job with the host. The reason Sandbox can be used with the feel of “another app” rather than “a heavy virtualisation product” is this cooperation.

The concrete procedure for using Sandbox to validate a business app is covered in the earlier “How to Speed Up App Validation with Windows Sandbox”. This article is the mechanism underneath that.

5. Containers — Where You Draw the Isolation Line

5.1. Process Isolation and Hyper-V Isolation

Windows containers have two isolation modes at run time. The image is shared; you choose with a flag at start.7

  • Process isolation: several containers share the kernel with the host and isolate through per-namespace virtualisation of the file system, registry, network ports, process-ID space, Object Manager namespace, and so on. It is essentially the same approach as Linux containers.
  • Hyper-V isolation: each container runs inside a highly optimised VM and has what is in effect a dedicated kernel. The presence of the VM puts hardware-level isolation between the containers and the host.7

Isolation through namespaces can be described as a thoroughgoing version of the technique we saw in the registry virtualisation article (“Registry Redirection and Virtualization on Windows”) — “show a different reality under the same API”.

Process isolation versus Hyper-V isolationUnder process isolation, containers share the kernel with the host and isolate through namespaces; under Hyper-V isolation, each container has a dedicated kernel inside an optimised VMHyper-V isolationProcess isolationDedicated kernel (inside an optimised VM)Container CDedicated kernel (inside an optimised VM)Container DKernel shared with the hostContainer AContainer B

Figure 11: Even with the same container image, whether you draw the isolation line above the kernel or split the kernel itself is a choice you make at start.

5.2. Which One Can You Call a “Security Boundary”

The difference between these two modes is not only a performance story. Microsoft does not consider a process-isolated container a robust security boundary. The containers that are maintained (with vulnerability response) as a security boundary are hypervisor-isolated containers, and Hyper-V isolation is what you should choose in an adversarial multi-tenant scenario.8

The VBS we saw in Part 2 was also a design that assumes “the kernel can be breached” and retreats to a hypervisor boundary. The same criterion applies in the world of containers. The line that confines untrusted code is drawn at the hypervisor boundary, not on the inside of a shared kernel.

How to choose isolation from how much you trust the codeIf the workload is trusted, take density and performance with process isolation; if the code is untrusted or someone else's, choose a hypervisor boundary such as a Hyper-V isolated container, a hardened Windows Sandbox with networking disabled, or an isolated VMYesNo / someone else's codeCan you trust that code?Process isolation (prioritise density and speed)Choose a hypervisor boundaryHyper-V isolated containersA hardened Sandbox or an isolated VM

Figure 12: Isolation mode is a security story before it is a performance story, and trust decides where you draw the line.

Incidentally, running a Hyper-V isolated container inside a Hyper-V VM makes the hypervisor two layers deep — nested virtualisation. One level of nesting is supported in production on environments that meet the conditions (an Intel processor with a Windows 10 / Windows Server 2016 or later host, or an AMD processor with a Windows 11 / Windows Server 2022 or later host, and the corresponding VM configuration version in each case), and a further prerequisite is a setting that exposes virtualisation extensions to the outer VM (ExposeVirtualizationExtensions on Set-VMProcessor in Hyper-V). Running WSL2 inside a VM is supported in the same way.9 Whether you can use WSL2 or Docker in a development VM in the cloud is also decided by whether that VM size and configuration expose nested virtualisation.

The structure of nested virtualisationA cloud VM sits on the physical host's hypervisor, and inside it another hypervisor (supported nesting is one level) runs to support WSL2 and Hyper-V isolated containersThe physical host's hypervisorCloud VM (dev machine)Hypervisor inside the VM (nesting level 1)WSL2Hyper-V isolated containerSupported nesting is one level

Figure 13: The reason wsl runs inside a cloud VM is that nested virtualisation is officially supported for one level only.

5.3. The Spectrum of Isolation and Lightness

Lining up the cast so far on a single axis, it looks like this.

The spectrum of isolation strength and lightnessProcess-isolated containers are the lightest but share the kernel; WSL2, Sandbox, and Hyper-V isolated containers are lightweight VMs with a dedicated kernel (Sandbox lightens by sharing, WSL2 by a purpose-built kernel); a full VM is the heaviest but general-purposeLight ← → HeavyProcess-isolated containers (shared kernel)WSL2, Sandbox, Hyper-V isolation (lightweight VMs with a dedicated kernel)Full VM (runs anything; holds a complete copy)Boundary: namespacesBoundary: hypervisorBoundary: hypervisor + complete independence

Figure 14: The lightweight-VM group is the middle solution that kept the hypervisor boundary and cut duplication; the way they cut it splits into sharing for Sandbox and a purpose-built kernel for WSL2.

6. See It for Yourself

Lightness and sharing are things you can observe on a machine in front of you.

Startup time and the rise and fall of memory (WSL2). With Task Manager open, try the following.

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

If you do a large build or file operation inside WSL2, vmmem grows, and you can observe it being returned all at once with wsl --shutdown.

The speed difference from where you put the files (WSL2). Put the same repository on the Linux side (~/repo) and on the Windows side (/mnt/c/repo) and compare the time for git status or an extraction, and the difference from Section 3.2 shows up in numbers.

Background for direct map (Sandbox). Start Sandbox and look at the increment in memory in Task Manager on the host. That the increment stays far smaller than what “another Windows” would lead you to imagine is the effect of sharing telling its story. To dig further into the host-side memory breakdown, the article on the Sysinternals tools that covers how to use RAMMap and VMMap (“Process Explorer / Handle / VMMap in Practice”) is useful. These are, however, tools for looking at the classification of host-side processes and physical memory; they do not directly observe the sharing with the guest itself.

Container isolation modes (Docker / Windows containers). If you have a Windows container environment, start the same image with docker run --isolation=process and --isolation=hyperv and compare startup time and how it looks in Task Manager (under process isolation, processes inside the container appear in the host’s process list), and you can feel where the isolation line sits.7 Process isolation, however, presupposes that the host and the image versions match, and on a client OS it is limited to development and test use. Hyper-V isolation allows a wider set of combinations, so do the comparison on a compatible pair.10

7. Three Misreadings to Avoid in Practice

7.1. “WSL2 Is Slow”

What is slow is not WSL2 but the file-I/O path that crosses an OS boundary. There are many cases where simply moving the project to the Linux side makes the feel a different thing.4 Conversely, putting files that Windows tools will touch on the Linux side is equally unfavourable for the same reason. Judge by “put it on the same OS as the side that uses it”.

7.2. “vmmem Growing Large Is a Memory Leak”

WSL2 memory grows and shrinks with demand, and released portions are returned. On current WSL, file cache is also reclaimed automatically by autoMemoryReclaim (the default is dropCache), so “it stayed large” often resolves over time.5 If it still remains, confirm that autoMemoryReclaim has not been set to disabled and that pageReporting, which is responsible for returning released portions, has not been turned off (or that you are not on older WSL), then either make the upper limit explicit with memory in .wslconfig or return everything with wsl --shutdown at a session boundary. The way of thinking about telling a leak from not-a-leak is the same as in the introductory instalment of the memory series, “What Does Windows’ “Memory Usage” Actually Mean?”.

7.3. “It’s in a Container, So It’s Safe”

A process-isolated container shares the kernel, and by Microsoft’s criterion it is not a security boundary.8 For running untrusted code or a specimen, choose isolation that has a hypervisor boundary, such as a Hyper-V isolated container, Windows Sandbox, or a dedicated VM. A hypervisor boundary, however, is not a blanket exemption. Windows Sandbox’s default settings have network connectivity enabled, and can expose an untrusted app to the internal network.1 If you use it to run a specimen, strengthen the isolation by disabling network and clipboard redirection in the .wsb configuration file, or use a dedicated VM on an isolated network.

8. Summary — Closing the Series

The points of Part 3.

  • The lightness of a lightweight VM is the result of “stopping duplication”, not of “weakening isolation”.
  • WSL2 runs a genuine Linux kernel in a managed lightweight utility VM, and distributions are isolated as containers inside that VM.3 The performance rule is to put files on the OS that uses them, and memory grows and shrinks dynamically, with the upper limit controllable in .wslconfig.45
  • Windows Sandbox shares the host’s immutable OS files through a dynamic base image and also shares the physical pages of the target OS binaries through direct map, so it does not hold a copy of a complete Windows.2 You still need about 500 MB for the mutable files, plus the memory of the apps you run inside it.
  • Container isolation mode is chosen at start, and the side you can call a security boundary is Hyper-V isolation.78

And if we put the whole series on one page, it looks like this.

  • Part 1: There is a hypervisor layer under Windows, and the host OS itself runs as the root partition. Arbitration of the CPU and of memory (SLAT) is done directly by this layer, and I/O of synthetic devices is mediated by the root partition (VSP) beyond the VMBus.
  • Part 2: That layer is used not only to isolate VMs from each other but also to draw a boundary stronger than the kernel (VTL) inside the same OS. Windows 11’s default security is built on top of this.
  • Part 3: On the same layer, cutting duplication is what makes “a virtual machine that starts in seconds” possible. The isolation line is kept, and it has become an everyday tool.
One picture of the whole seriesThe hypervisor directly on the hardware is Part 1; the split of VTL0 and VTL1 inside the host Windows is Part 2; the lightness of WSL2, Sandbox, and Hyper-V isolation on the same layer is Part 3; process-isolated containers share the host kernel; Sandbox lightens by sharing, WSL2 by a purpose-built kernelHardwareHypervisor (Part 1)Host Windows (VTL isolation is Part 2)WSL2, Sandbox, Hyper-V isolation (Part 3)Process-isolated containers (shared kernel)Sandbox shares; WSL2 lightens with a purpose-built kernel

Figure 15: Stack the three instalments and you have the overall picture of the ground under current Windows.

Virtualisation is no longer a server-room technology, nor a technology only for people who stand up VMs. At the ground under your Windows, it quietly supports both security and the development experience — that is where we are now.

KomuraSoft LLC handles setting up development environments that use WSL2 and containers, designing Windows app validation environments, and investigating performance and compatibility in virtualised environments.

References

  1. Microsoft Learn, Windows Sandbox. On Windows Sandbox starting in a few seconds as a disposable VM and discarding everything when closed; on running a separate kernel with the Microsoft hypervisor to isolate it from the host; and on network connectivity being enabled by default and disableable in the configuration file. ↩ ↩2 ↩3

  2. Microsoft Learn, Windows Sandbox architecture. On a dynamic base image assembling a complete Windows image from a share of the host’s immutable OS files plus a clean copy of the mutable files (about 500 MB after installation); on a container allocating dynamically in cooperation with the host, against the static memory allocation of a traditional VM, so that the host can reclaim memory; and on direct map making OS binaries such as ntdll.dll use the same physical pages as the host. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Microsoft Learn, What is the Windows Subsystem for Linux?. On WSL2 running a Linux kernel inside a lightweight utility VM; on each distribution running as an isolated container, sharing the network namespace and the kernel while separating namespaces such as PID, mount, and user. ↩ ↩2 ↩3

  4. Microsoft Learn, Comparing WSL Versions. On the WSL2 kernel being built by Microsoft from the Stable branch; on Store-distributed WSL receiving updates as a package detached from the OS image and applying them with wsl --update (on the older in-box distribution, through Windows Update); on performance examples such as up to 20x for tarball extraction; on WSL1 being faster for cross-OS file-system performance, so files should be placed on the OS that uses them; and on memory growing and shrinking with released portions returned, while cache may not return until the VM exits. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  5. Microsoft Learn, Advanced settings configuration in WSL. On being able to set the WSL2 VM’s overall memory ceiling, processor count, swap, and pageReporting (enabled by default; responsible for detecting and returning unused memory) in the [wsl2] section of .wslconfig; and on the experimental setting autoMemoryReclaim defaulting to dropCache, so that cache memory is reclaimed automatically. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Use and configure Windows Sandbox. On MappedFolders in the .wsb configuration file being able to share a host folder as read-only or writable. ↩

  7. Microsoft Learn, Isolation Modes. On process isolation of Windows containers sharing the kernel with the host and isolating through namespaces; on Hyper-V isolation having what is in effect a dedicated kernel inside an optimised VM; and on the same image being runnable in either mode through a flag at start. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, Secure Windows containers. On only hypervisor-isolated containers being treated as a security boundary; on process-isolated containers not being considered a robust security boundary; and on hypervisor isolation being what you should choose in an adversarial multi-tenant scenario. ↩ ↩2 ↩3

  9. Microsoft Learn, What is Nested Virtualization?. On running Hyper-V isolated containers inside a Hyper-V VM (one level of nesting) being supported in production; on the requirements being an Intel processor with Windows Server 2016 / Windows 10 or later, or an AMD processor with Windows Server 2022 / Windows 11 or later, plus the corresponding VM configuration version in each case; on exposing virtualisation extensions to the outer VM (ExposeVirtualizationExtensions) being a prerequisite; and on running WSL2 inside a Hyper-V VM being supported. ↩

  10. Microsoft Learn, Windows container version compatibility. On process isolation presupposing that the host and the container image versions match; on Hyper-V isolation being able to run an image of an OS version different from the host; and on process isolation on a client OS being limited to development and test use. ↩

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is WSL2 a VM?
Yes. WSL2 runs a genuine Linux kernel built by Microsoft inside a lightweight utility VM. The VM is managed by WSL behind the scenes, so the design never makes the user think about VM settings or waiting for a boot. Each Linux distribution runs as an isolated container inside this managed VM.
Why are file operations under /mnt/c slow in WSL2?
Because access from the WSL2 Linux kernel to the Windows-side file system goes through file sharing that crosses an OS boundary. Operations on the Linux file system (an ext4 virtual disk) are fast, so the rule is to keep project files on the same OS side as the tools that work on them.
Is a large memory usage by the vmmem process a leak?
In most cases it is not a leak. WSL2 memory grows and shrinks with use, and memory that processes have released is returned to Windows under the pageReporting setting, which is enabled by default. File-cache pages, too, are reclaimed automatically by current WSL via autoMemoryReclaim in .wslconfig (the default is dropCache). In environments where these settings have been disabled, or on older WSL, the memory can remain until the VM exits; in that case set an upper limit with the memory setting, or return it with wsl --shutdown.
How can Windows Sandbox boot a complete Windows from a few hundred megabytes of disk?
Through a mechanism called a dynamic base image. It shares the immutable OS files from the Windows already installed on the host, and keeps a clean copy of only the small number of mutable files. That lets it assemble a complete, bootable image without storing a full copy of Windows.
Are containers safer than VMs?
It depends on the isolation mode. Process-isolated containers share the kernel with the host, and Microsoft does not consider this a robust security boundary. When you handle adversarial code, you need Hyper-V isolation, which gives each container its own dedicated kernel.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.

Contact
Back to the Blog