Die Tiefen der Windows-Virtualisierung (Teil 3) — Virtuelle Maschinen, die in Sekunden starten: Warum WSL2, Windows Sandbox und Container so leicht sind

Eine volle VM ist schwer — warum sind WSL2 und Windows Sandbox dann leicht? Die letzte Folge der Reihe erklärt den Unterschied nicht nur aus „was isoliert wird“, sondern aus „was nicht verdoppelt werden muss“.

Wenn Sie im Hyper-V-Manager eine Windows-VM anlegen, dauert der Start Dutzende von Sekunden und belegt mehrere Gigabyte Speicher. Auf demselben PC gibt wsl innerhalb weniger Sekunden eine Linux-Shell zurück, und Windows Sandbox öffnet ebenfalls in wenigen Sekunden einen wegwerfbaren Desktop.¹

Die Grundlage ist in allen Fällen der Windows-Hypervisor aus Teil 1. In Teil 2 haben wir bestätigt, dass diese Grundlage Isolierung aufbauen kann, die stärker ist als der Kernel. Dieser Artikel betrachtet getrennt die Spezialisierung von WSL2, das Teilen von Sandbox und die Isolierungsmodi von Containern.

„Die Tiefen der Windows-Virtualisierung“ — Alle 3 Teile

Wir betrachten denselben Windows-Hypervisor in der Reihenfolge Grundlage → Sicherheitsisolierung → Anwendung auf leichte VMs.

Voraussetzungen für diesen Artikel

Wie Sie diesen Artikel lesen

1. Zuerst das Fazit

Eine leichte VM behält die Isolierungslinie (einen eigenen Kernel und die Hypervisor-Grenze) und erleichtert die „Kopie eines vollständigen Gastbetriebssystems“. Sandbox teilt das Windows des Hosts selbst, WSL2 ersetzt den Gast durch ein kleines, zweckbestimmtes Linux, und in beiden Fällen ist Speicher keine feste Reservierung, sondern wird dynamisch mit dem Host verliehen und zurückgegeben.

Die Quelle des Gewichts einer vollen VM ist nicht die Isolierung selbst, sondern Verdopplung. Ein weiteres Betriebssystemabbild auf dem Datenträger, eine weitere Betriebssystemmenge an Seiten im RAM, und bei jedem Start ein weiterer voller Boot. Die leichten VMs schneiden diese Verdopplung mit zwei Politiken: „teilen, was sicher zu teilen ist“ (Sandbox) und „wenn es nicht geteilt werden kann, klein neu bauen“ (WSL2).

flowchart TB
    accTitle: Drei Arten des Teilens, die leichte VMs tragen
    accDescr: Das Betriebssystemabbild, das eine volle VM verdoppelte, wird durch Teilen in Sandbox und durch Verkleinern in WSL2 geschnitten, Speicher der standardmäßig fest zugeteilt ist (Konfigurationen mit dynamischem Speicher sind die Ausnahme) wird zu dynamischem Leihen und Zurückgeben mit dem Host, und der Start wird durch einen leichten Kernel und eine minimale Konfiguration ersetzt, sodass nur die Isolierungsgrenze bleibt
    heavy["Die Quelle des Gewichts einer vollen VM ist Verdopplung"] --> d1["Datenträger: Kopie des Betriebssystemabbilds"]
    heavy --> d2["Speicher: feste Zuteilung als Grundsatz"]
    heavy --> d3["Start: noch einmal ein voller Boot"]
    d1 -->|ersetzt durch| s1["Teilen (Sandbox) oder Verkleinern (WSL2)"]
    d2 -->|ersetzt durch| s2["Dynamisches Leihen und Zurückgeben mit dem Host"]
    d3 -->|ersetzt durch| s3["Verkürzt durch leichten Kernel und minimale Konfiguration"]

Abbildung 1: Sie haben aufgehört zu verdoppeln, nicht zu isolieren, und das ist das Gerüst der Antwort auf „derselbe Hypervisor, und doch leicht“.

Im Folgenden betrachten wir der Reihe nach WSL2, Windows Sandbox und Container und welche Verdopplung jedes von ihnen schneidet.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (19 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Was eine volle VM mit sich trägt

Als Vergleichsmaßstab halten wir fest, was eine herkömmliche VM mit sich trägt.

• Ein unabhängiges Betriebssystemabbild. Sie hält jede Datei des Gastbetriebssystems in einer virtuellen Festplatte. Selbst wenn der Host dasselbe Windows ausführt, wird nichts geteilt.
• Grobe Speicherzuteilung. Eine herkömmliche VM teilt Hostspeicher standardmäßig in einer statischen Größe zu. Es gibt Mechanismen wie den dynamischen Speicher von Hyper-V, die die Zuteilung innerhalb eines konfigurierten Bereichs wachsen und schrumpfen lassen, aber die Mittel, auf Nachfrageänderungen zu reagieren, sind begrenzt.²
• Ein allgemeiner voller Boot. Firmware, Bootloader und Dienste starten in derselben Reihenfolge wie auf einer physischen Maschine.

flowchart TB
    accTitle: Die drei Lasten einer vollen VM
    accDescr: Eine volle VM trägt ein unabhängiges Betriebssystemabbild, eine Speicherzuteilung die standardmäßig statisch ist und einen allgemeinen vollen Boot, und das zeigt sich als Kosten bei Datenträger, RAM und Startzeit
    fullvm["Volle VM"] --> b1["Unabhängiges Betriebssystemabbild"]
    fullvm --> b2["Speicherzuteilung, die standardmäßig statisch ist"]
    fullvm --> b3["Allgemeiner voller Boot"]
    b1 -.-> c1["Verbraucht Datenträger für die Kopie"]
    b2 -.-> c2["Neigt dazu, RAM zu halten den sie nicht nutzt"]
    b3 -.-> c3["Braucht Dutzende von Sekunden zum Start"]

Abbildung 2: Jeder Posten in der Kostenaufstellung einer vollen VM wird für Allgemeinheit und Verdopplung bezahlt, nicht für Isolierung.

Das sind keine Mängel, sondern der Preis der Allgemeinheit, in den Gast alles hineinlegen zu können. Für einen Einsatz wie ein altes Linux neben Windows Server ist genau diese Allgemeinheit der Wert. Wenn der Bedarf aber lautet „dasselbe Betriebssystem wie der Host (oder ein festes) jetzt gleich für Entwicklung oder Validierung starten“, wird der größte Teil tote Last. Leichte VMs legen dieses Gepäck ab, indem sie den Zweck eingrenzen.

3. WSL2 — Eine Utility-VM mit einem zweckbestimmten Kernel

WSL2 lässt sich am klarsten in der Reihenfolge Struktur → wo Dateien liegen → Speicher zurückgeben lesen. Einen echten Linux-Kernel zu nutzen und Dateien der Windows-Seite schnell zu behandeln, sind zwei verschiedene Dinge.

3.1. Struktur: Eine verwaltete VM und die Distributionen darin

WSL2 ist ein Mechanismus, der in einer leichten Utility-VM einen echten Linux-Kernel ausführt.³ Drei Punkte sind entscheidend.

Der Kernel ist echt, aber spezialisiert

Es ist ein Linux-Kernel, den Microsoft aus dem Stable-Zweig baut und in Größe und Leistung auf WSL2 abstimmt. Beim heutigen Standard, dem über den Microsoft Store verteilten WSL, wird der Kernel zusammen mit dem WSL-Paket selbst aktualisiert und mit wsl --update angewendet (die ältere, in Windows eingebaute Verteilung erhielt ihn über Windows Update).⁴

Weil es ein echter Kernel ist, ist die Systemaufrufkompatibilität vollständig, und Werkzeuge wie Docker laufen unverändert.

Die VM bleibt hinter den Kulissen

WSL verwaltet das Anlegen, Starten und Beenden der VM; der Nutzer öffnet nur eine Shell. Es gibt weder einen Bildschirm für VM-Einstellungen noch ein spürbares Warten auf einen Boot.⁴

Distributionen sind Container in der VM

Jede Distribution, etwa Ubuntu oder Debian, läuft als isolierter Container in einer einzigen verwalteten VM. Netz-Namespace und Kernel werden geteilt, während Namespaces wie PID, Mount und Benutzer getrennt sind.³

flowchart TB
    accTitle: Architektur von WSL2
    accDescr: Auf dem Hypervisor sitzen das Host-Windows und eine leichte Utility-VM nebeneinander, in der VM läuft ein von Microsoft gebauter Linux-Kernel, und jede Distribution läuft darin als isolierter Container
    hv["Hypervisor"] --> host["Host-Windows"]
    hv --> uvm["Leichte Utility-VM"]
    uvm --> lk["Linux-Kernel (Microsoft-Build, Aktualisierung mit wsl --update)"]
    lk --> u1["Ubuntu (Container)"]
    lk --> u2["Debian (Container)"]
    host <-->|"Interop (Befehle, Dateien, Netz)"| uvm

Abbildung 3: Die Antwort auf „ist WSL2 eine VM?“ lautet „ja, aber eine verwaltete VM, die unsichtbar bleibt“, und selbst mit mehreren Distributionen gibt es nur eine VM.

Hinter der Kulisse im Moment, in dem Sie wsl tippen, geschieht Folgendes.

flowchart TB
    accTitle: Vom Ausführen des Befehls wsl bis zur Shell in wenigen Sekunden
    accDescr: Wenn wsl läuft, werden die leichte VM und der Linux-Kernel gestartet falls die Utility-VM noch nicht läuft, die vorhandene VM wird unverändert genutzt falls sie läuft, und in dem Container der Distribution kehrt eine Shell zurück
    cmd["wsl ausführen"] --> vmq{"Läuft die Utility-VM bereits?"}
    vmq -->|Nein| bootvm["Leichte VM und Linux-Kernel starten (wenige Sekunden)"]
    vmq -->|Ja| reuse["Die laufende VM unverändert nutzen"]
    bootvm --> shell["Eine Shell kehrt im Container zurück"]
    reuse --> shell

Abbildung 4: Die Wartezeit ist nichts weiter als ein minimaler VM-Start, und hier zahlt sich das Ablegen des Gepäcks eines vollen Boots aus.

3.2. Datei-E/A: Auf welcher Seite die Dateien liegen, macht den Unterschied

Wo Dateien liegen, kommt in jeder Diskussion über die Leistung von WSL2 vor.

• Operationen auf Dateien der Linux-Seite (der virtuellen ext4-Festplatte) sind schnell. Der Linux-Kernel behandelt sein eigenes Dateisystem direkt, und Beschleunigungen von bis zu 20× gegenüber WSL1 beim Entpacken von Tarballs sowie 2- bis 5× bei git clone und npm install sind berichtet.⁴
• Operationen auf Dateien der Windows-Seite (/mnt/c und Ähnliches) sind langsamer, weil sie über eine Dateifreigabe laufen, die die Betriebssystemgrenze überquert. Die Leistung über Betriebssystemdateisysteme hinweg ist der eine große Punkt, in dem WSL2 hinter WSL1 zurückbleibt.⁴

Die Regel lautet daher: legen Sie Projektdateien auf dieselbe Betriebssystemseite wie die Werkzeuge, die sie behandeln.⁴ Ein Repository, das Linux-Buildwerkzeuge behandeln, gehört auf die Linux-Seite; eine Lösung, die in Visual Studio gebaut wird, auf die Windows-Seite.

flowchart TB
    accTitle: Die Gabelung der Datei-E/A-Pfade von WSL2
    accDescr: Zugriff auf die virtuelle ext4-Festplatte der Linux-Seite ist schnell weil der Linux-Kernel sie direkt erreicht, während Zugriff auf Dateien der Windows-Seite langsam ist weil er über eine Dateifreigabe läuft die die Betriebssystemgrenze überquert
    io["Dateioperation in WSL2"] --> place{"Auf welcher Seite liegt die Datei?"}
    place -->|"Linux-Seite (Home-Verzeichnis usw.)"| ext4["Direkte E/A zur virtuellen ext4-Festplatte"]
    place -->|"Windows-Seite (/mnt/c usw.)"| p9["Über eine Freigabe die die Betriebssystemgrenze überquert"]
    ext4 --> fast["Schnell (bis zu 20x gegenüber WSL1 in einem Beispiel)"]
    p9 --> slow["Neigt dazu langsam zu sein"]
    slow -.-> fix["Abhilfe: Datei auf das Betriebssystem legen das sie nutzt"]

Abbildung 5: Langsam ist der Pfad, nicht WSL2; oft verschwindet das Leistungsproblem allein dadurch, wo die Dateien liegen.

3.3. Speicher: Er wächst, er schrumpft, aber er gibt nicht alles zurück

Die Speichernutzung von WSL2 (im Task-Manager als Prozess vmmem sichtbar) ist keine feste Reservierung; sie wächst und schrumpft mit der Nutzung.

Zurückgeben von Speicher, den Prozesse freigegeben haben

Speicher, den Prozesse freigegeben haben, wird unter der Einstellung pageReporting, die standardmäßig aktiviert ist, automatisch an Windows zurückgegeben.⁵

Einziehen des Dateicaches

Seiten, die als Dateicache gehalten wurden, kehrten früher erst beim Beenden der VM an Windows zurück.⁴ In aktuellem WSL zieht die experimentelle Einstellung autoMemoryReclaim in .wslconfig (Voreinstellung dropCache) auch den Cache automatisch ein.⁵

In Umgebungen, in denen diese Einstellung disabled ist, oder auf älterem WSL kann der Cache einer langen Sitzung bis zum Beenden der VM bleiben und den Hostspeicher belasten.

flowchart TB
    accTitle: Wie der Speicher von WSL2 wächst, schrumpft und zurückgegeben wird
    accDescr: Steigende Nachfrage in WSL2 hebt die Speichernutzung der VM, von Prozessen freigegebener Speicher wird unter dem standardmäßig aktivierten pageReporting an Windows zurückgegeben, der Dateicache wird standardmäßig von autoMemoryReclaim automatisch eingezogen, bei deaktivierter Einstellung oder älterem WSL bleibt er bis zum Beenden der VM, und wsl shutdown gibt alles zurück
    grow["Speichernachfrage in WSL2 steigt"] --> vm["Nutzung von vmmem steigt"]
    vm --> freed{"Ist diese Seite freigegeben?"}
    freed -->|"Von einem Prozess freigegeben (mit pageReporting aktiv)"| ret["Automatisch an Windows zurückgegeben"]
    freed -->|Als Dateicache gehalten| amr["Automatisch von autoMemoryReclaim eingezogen (Voreinstellung)"]
    amr -.-> old2["Bleibt bis zum Beenden der VM wenn deaktiviert oder auf älterem WSL"]
    old2 --> sd["wsl --shutdown gibt alles zurück"]

Abbildung 6: Was wie „es wächst nur“ aussieht, ist vor allem der Cache (bei deaktiviertem pageReporting bleibt auch von Prozessen freigegebener Speicher); kennen Sie die Rückgabepfade, bevor Sie es ein Leck nennen.

Eine Speicherobergrenze setzen

Wenn Sie eine ausdrückliche Obergrenze wollen, steuert %UserProfile%\.wslconfig Speicher, Prozessorzahl und Swap der VM insgesamt.⁵

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

Nach einer Änderung der Einstellungen starten Sie die VM mit wsl --shutdown neu, damit sie wirksam werden. Diese dynamische Zuteilung, bei der eine Einstellung die Obergrenze festlegt und die Nachfrage die tatsächliche Nutzung, treibt Windows Sandbox, das als Nächstes kommt, noch weiter.

4. Windows Sandbox — Das Windows des Hosts noch einmal nutzen

Die Leichtigkeit von Sandbox zerfällt in drei Teile: Teilen von Betriebssystemdateien auf dem Datenträger, Teilen von Betriebssystemseiten im RAM und Abstimmen der Speicherzuteilung mit dem Host.

4.1. Dynamisches Basisabbild: Ein vollständiges Windows in 500 MB

Windows Sandbox ist ein wegwerfbarer Windows-Desktop, den der Hypervisor isoliert. Schließen Sie ihn, verschwindet alles; beim nächsten Mal startet er in wenigen Sekunden aus einem unberührten Zustand.¹

Das erste Rätsel ist der Datenträger. Er kann ein vollständiges Windows starten, und doch ist das Basisabbild von Sandbox nach der Installation nur etwa 500 MB groß und für die Verteilung auf 30 MB komprimiert.² Das Geheimnis ist das dynamische Basisabbild.

• Die meisten Betriebssystemdateien sind unveränderlich (immutable) und können unverändert vom Host geteilt werden.
• Nur die wenigen veränderlichen (mutable) Dateien können nicht geteilt werden, daher hält das Basisabbild eine saubere Kopie von ihnen.
• Beim Start werden die unveränderlichen Dateien des Hosts und die lokalen Kopien der veränderlichen Dateien zu einem vollständigen Windows-Abbild kombiniert.²

Mit anderen Worten: Sandbox lädt weder eine Kopie von Windows herunter noch speichert sie eine; sie startet, indem sie das bereits auf dem Host installierte Windows wiederverwendet.

flowchart TB
    accTitle: Wie das dynamische Basisabbild zusammengesetzt wird
    accDescr: Die unveränderlichen Betriebssystemdateien des Host-Windows werden geteilt, nur die veränderlichen Dateien werden als saubere Kopie im Basisabbild gehalten, und beides wird zum vollständigen Windows-Abbild von Sandbox kombiniert
    hostw["Das vollständige Windows des Hosts"] --> imm["Unveränderliche Betriebssystemdateien (die große Mehrheit)"]
    hostw --> mut["Veränderliche Betriebssystemdateien (wenige)"]
    imm -->|unverändert geteilt| img["Startabbild von Sandbox"]
    mut -->|saubere Kopie gehalten| img
    img --> boot["Startet als vollständiges Windows"]
    img -.-> size["Nur etwa 500 MB müssen gespeichert werden"]

Abbildung 7: Nicht „noch ein Windows halten“, sondern „eines aus dem Windows des Hosts zusammenbauen“ ist die Form, in der die Verdopplung auf dem Datenträger aufgegeben wird.

Genau diese Zusammensetzung macht den folgenden Lebenszyklus möglich.

Was verworfen wird, ist der lokale Zustand innerhalb von Sandbox.

Wenn Sie in der .wsb-Konfigurationsdatei einen beschreibbaren Ordner vom Host zuordnen, bleiben Änderungen daran auf der Host-Seite.⁶

flowchart TB
    accTitle: Lebenszyklus von Windows Sandbox
    accDescr: Der Start bereitet in wenigen Sekunden ein unberührtes Windows vor, nach Validierung oder Experimenten verwirft das Schließen den gesamten Zustand in Sandbox sodass der nächste Start wieder unberührt ist, Änderungen an einem als beschreibbar zugeordneten Host-Ordner bleiben jedoch
    launch["Start (wenige Sekunden)"] --> clean["Ein unberührtes Windows"]
    clean --> work["Validierung von Apps oder Experimente"]
    work --> close2["Schließen"]
    close2 --> discard["Den gesamten Zustand in Sandbox verwerfen"]
    discard -.-> mapped["Änderungen in einem zugeordneten beschreibbaren Ordner bleiben auf dem Host"]
    discard -->|nächster Start| launch

Abbildung 8: Jedes Mal in den unberührten Zustand zurückzukehren gelingt, weil der veränderliche Teil eine wegwerfbare Kopie ist, und das Verwerfen ist Teil der Konstruktion.

4.2. Direct Map: Dieselbe ntdll.dll ist dieselbe physische Seite

Nicht nur der Datenträger, auch der RAM wird geteilt. Weil Sandbox dasselbe Betriebssystemabbild wie der Host ausführt, kommt eine Technik namens „Direct Map“ zum Einsatz, sodass Betriebssystembinärdateien dieselben physischen Speicherseiten wie der Host nutzen. Wenn ntdll.dll in Sandbox in den Speicher geladen wird, zeigt sie auf dieselben physischen Seiten wie dieselbe Binärdatei auf dem Host.

Das erreicht einen deutlich kleineren Speicherbedarf als eine herkömmliche VM, ohne die Geheimnisse des Hosts einem Risiko auszusetzen.²

„Dieselbe physische Seite unter mehreren Nutzern teilen“ — das ist dieselbe Idee wie das Teilen von DLLs über Abschnittsobjekte, dem wir in Teil 3 der Speicherreihe nachgegangen sind („Abschnittsobjekte und Copy-on-Write“). Jener Mechanismus teilte zwischen Prozessen; Sandbox tut es über die VM-Grenze hinweg.

flowchart TB
    accTitle: Teilen physischer Seiten durch Direct Map
    accDescr: Eine App auf dem Host und eine App in Sandbox teilen dieselben physischen Speicherseiten für Betriebssystembinärdateien wie ntdll und senken so die Speichernutzung
    happ["App auf dem Host"] --> hva["Virtuelle Adresse der Host-Seite"]
    sapp["App in Sandbox"] --> sva["Virtuelle Adresse der Sandbox-Seite"]
    hva --> phys["Dieselbe physische Seite (Betriebssystembinärdateien wie ntdll.dll)"]
    sva --> phys
    phys -.-> save["Keine Verdopplung des Betriebssystemanteils am RAM nötig"]

Abbildung 9: Direct Map nimmt die Idee des Seitenteilens, die lange zwischen Prozessen genutzt wurde, und wendet sie über die VM-Grenze hinweg an.

4.3. Leihen und Zurückgeben von Speicher: Eher wie ein Prozess als wie eine VM

Im Gegensatz zur statischen Speicherzuteilung einer herkömmlichen VM entscheidet die Containertechnik unter Sandbox die Ressourcenzuteilung dynamisch in Abstimmung mit dem Host. Wird dem Host der Speicher knapp, kann er Speicher vom Container zurückholen, genau wie von einem gewöhnlichen Prozess.² Der dynamische Speicher von Hyper-V lässt die Zuteilung einer VM ebenfalls innerhalb eines konfigurierten Bereichs wachsen und schrumpfen, aber Sandbox geht einen Schritt weiter: Sie teilt Speicher auf demselben Spielfeld wie die eigene Speicherverwaltung des Hosts.

flowchart TB
    accTitle: Abstimmung des Speichers zwischen Host und Sandbox
    accDescr: Eine herkömmliche VM reserviert standardmäßig eine statische Größe mit begrenzten Anpassungsmitteln, während Sandbox bei Speicherdruck des Hosts zum Ziel des Zurückholens wird und Speicher auf demselben Spielfeld wie gewöhnliche Prozesse teilt
    pressure["Speicherdruck des Hosts steigt"] --> from{"Woher zurückholen?"}
    from --> proc["Die Working Sets gewöhnlicher Prozesse"]
    from --> sbx["Was Sandbox (der Container) nutzt"]
    proc --> relief["Freier Speicher wird gesichert"]
    sbx --> relief
    relief -.-> contrast["Eine herkömmliche VM hat begrenzte Anpassungsmittel"]

Abbildung 10: Beim Teilen von Speicher steht Sandbox auf der Seite der Prozesse, nicht der VMs, und gibt Speicher ab, wenn der Host unter Druck steht.

In Teil 1 haben wir gesagt, dass die Leistung einer VM auch von der Host-Seite abhängt; bei leichten VMs geht das einen Schritt weiter, und die Speicherzuteilung selbst wird zur gemeinsamen Arbeit mit dem Host. Diese Abstimmung ist der Grund, warum sich Sandbox weniger wie „schwere Virtualisierungssoftware“ und mehr wie nur eine weitere App anfühlt.

Die konkreten Schritte, Sandbox zur Validierung von Geschäftsanwendungen zu nutzen, behandelt der frühere Artikel „Wie Sie mit Windows Sandbox die App-Validierung beschleunigen“. Dieser Artikel behandelt den Mechanismus darunter.

5. Container — Wo die Isolierungslinie gezogen wird

Hier beurteilen wir Sicherheit nicht allein am Namen „Container“; wir prüfen, ob der Container den Kernel mit dem Host teilt oder einen eigenen Kernel hat.

5.1. Prozessisolierung und Hyper-V-Isolierung

Windows-Container haben zwei Isolierungsmodi zur Laufzeit. Das Abbild ist dasselbe; Sie wählen den Modus mit einem Flag beim Start.⁷

• Prozessisolierung: mehrere Container teilen den Kernel mit dem Host und werden durch Virtualisierung je Namespace von Dateisystem, Registrierung, Netzports, Prozess-ID-Raum, Namespace des Objekt-Managers und so weiter isoliert. Das ist fast dieselbe Vorgehensweise wie bei Linux-Containern.
• Hyper-V-Isolierung: jeder Container läuft in einer stark optimierten VM und hat faktisch einen eigenen Kernel. Durch die Anwesenheit der VM entsteht Isolierung auf Hardwareebene zwischen den Containern und zwischen ihnen und dem Host.⁷

Isolierung über Namespaces lässt sich als konsequente Fassung der Technik aus dem Artikel zur Registrierungsvirtualisierung sehen („Registry-Umleitung und Virtualisierung unter Windows“): unter derselben API eine andere Entität zeigen.

flowchart TB
    accTitle: Prozessisolierung gegenüber Hyper-V-Isolierung
    accDescr: Unter Prozessisolierung teilen Container den Kernel mit dem Host und werden über Namespaces isoliert, unter Hyper-V-Isolierung hat jeder Container einen eigenen Kernel in einer optimierten VM
    subgraph pi ["Prozessisolierung"]
        c1["Container A"] --> sk1["Mit dem Host geteilter Kernel"]
        c2["Container B"] --> sk1
    end
    subgraph hi ["Hyper-V-Isolierung"]
        c3["Container C"] --> k3["Eigener Kernel (in einer optimierten VM)"]
        c4["Container D"] --> k4["Eigener Kernel (in einer optimierten VM)"]
    end
    sk1 ~~~ c3

Abbildung 11: Selbst mit demselben Containerabbild wählen Sie beim Start, ob die Isolierungslinie oberhalb des Kernels gezogen wird oder der Kernel selbst getrennt ist.

5.2. Welche Seite sich „Sicherheitsgrenze“ nennen darf

Der Unterschied der beiden Modi bleibt nicht bei der Leistung. Microsoft betrachtet prozessisolierte Container nicht als robuste Sicherheitsgrenze. Als Sicherheitsgrenze (mit Behandlung von Schwachstellen) gepflegt werden die hypervisor-isolierten Container, und in gegnerischen Multi-Tenant-Szenarien ist Hyper-V-Isolierung der zu wählende Modus.⁸

Auch das VBS aus Teil 2 war auf der Prämisse „der Kernel kann gebrochen werden“ entworfen und weicht auf die Hypervisor-Grenze zurück. Dasselbe Kriterium gilt in der Welt der Container. Die Linie, die nicht vertrauenswürdigen Code einschließt, wird an der Hypervisor-Grenze gezogen, nicht innerhalb eines geteilten Kernels.

flowchart TB
    accTitle: Isolierung nach dem Vertrauensgrad des Codes wählen
    accDescr: Eine vertrauenswürdige Last nimmt Dichte und Leistung mit Prozessisolierung, nicht vertrauenswürdiger Code oder Code anderer erhält eine Hypervisor-Grenze wie einen Hyper-V-isolierten Container, eine gehärtete Windows Sandbox mit deaktiviertem Netz und Ähnlichem oder eine isolierte VM
    trust{"Kann dieser Code vertraut werden?"} -->|Ja| dens["Prozessisolierung (Dichte und Tempo zuerst)"]
    trust -->|"Nein, oder Code anderer"| bound["Eine Hypervisor-Grenze wählen"]
    bound --> opt1["Hyper-V-isolierter Container"]
    bound --> opt2["Gehärtete Sandbox oder isolierte VM"]

Abbildung 12: Der Isolierungsmodus ist zuerst eine Sicherheitsfrage und dann eine Leistungsfrage, und der Vertrauensgrad entscheidet, wo die Linie liegt.

Hinweis: In einer VM die Anforderungen der geschachtelten Virtualisierung prüfen

Hyper-V-isolierte Container in einer Hyper-V-VM auszuführen bedeutet zwei Hypervisor-Schichten: geschachtelte Virtualisierung.

Eine Ebene der Schachtelung wird in Produktion auf Umgebungen unterstützt, die die Bedingungen erfüllen (ein Host mit Windows 10 / Windows Server 2016 oder später für Intel-Prozessoren, ein Host mit Windows 11 / Windows Server 2022 oder später für AMD-Prozessoren, plus jeweils die passende VM-Konfigurationsversion), und sie verlangt zusätzlich die Einstellung, die Virtualisierungserweiterungen an die äußere VM weitergibt (ExposeVirtualizationExtensions an Set-VMProcessor für Hyper-V).

WSL2 in einer VM auszuführen wird auf dieselbe Weise unterstützt.⁹ Ob Sie WSL2 oder Docker auf einer Entwicklungs-VM in der Cloud nutzen können, hängt ebenfalls davon ab, ob Größe und Konfiguration dieser VM geschachtelte Virtualisierung weitergeben.

flowchart TB
    accTitle: Die Struktur der geschachtelten Virtualisierung
    accDescr: Eine Cloud-VM sitzt auf dem Hypervisor des physischen Hosts, und darin läuft ein weiterer Hypervisor (Schachtelung wird nur für eine Ebene unterstützt) der WSL2 und Hyper-V-isolierte Container trägt
    phys3["Hypervisor des physischen Hosts"] --> cvm["Cloud-VM (Entwicklungsrechner)"]
    cvm --> nhv["Hypervisor in der VM (erste Ebene der Schachtelung)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V-isolierter Container"]
    nhv -.-> limit["Schachtelung wird nur für eine Ebene unterstützt"]

Abbildung 13: Dass wsl in einer Cloud-VM läuft, liegt daran, dass geschachtelte Virtualisierung offiziell für genau eine Ebene unterstützt wird.

5.3. Das Spektrum von Isolierung und Leichtigkeit

Alles bisher Behandelte auf einer Achse aufzureihen ergibt Folgendes.

flowchart TB
    accTitle: Das Spektrum von Isolierungsstärke und Leichtigkeit
    accDescr: Prozessisolierte Container sind am leichtesten teilen aber den Kernel, WSL2, Sandbox und Hyper-V-isolierte Container sind leichte VMs mit eigenem Kernel (Sandbox erleichtert durch Teilen mit dem Host, WSL2 durch einen zweckbestimmten Kernel), und eine volle VM ist am schwersten aber allgemein
    ax["Leicht ← → Schwer"] ~~~ p1
    p1["Prozessisolierter Container (geteilter Kernel)"] --> p2["WSL2, Sandbox, Hyper-V-Isolierung (leichte VMs mit eigenem Kernel)"]
    p2 --> p3["Volle VM (führt alles aus, hält jede Kopie)"]
    p1 -.-> n1["Grenze: Namespaces"]
    p2 -.-> n2["Grenze: Hypervisor"]
    p3 -.-> n3["Grenze: Hypervisor + vollständige Unabhängigkeit"]

Abbildung 14: Die leichten VMs sind die mittlere Lösung, die die Hypervisor-Grenze behielt und die Verdopplung schnitt; wie sie schneiden, unterscheidet sich, mit Teilen bei Sandbox und einem zweckbestimmten Kernel bei WSL2.

6. Mit eigenen Augen prüfen

Leichtigkeit und Teilen lassen sich auf dem eigenen Rechner beobachten.

6.1. Startzeit von WSL2 und Wachsen und Schrumpfen des Speichers

Lassen Sie den Task-Manager geöffnet und versuchen Sie Folgendes.

# Empfundene Startzeit (der erste Lauf startet die VM; spätere Läufe sind noch schneller)
Measure-Command { wsl -e true }

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

# Die gesamte VM beenden und beobachten, wie der Speicher zurückkehrt
wsl --shutdown

Führen Sie in WSL2 einen großen Build oder eine Dateioperation aus, wächst vmmem; wsl --shutdown gibt alles auf einmal zurück, und Sie können es beobachten.

6.2. Geschwindigkeitsunterschiede durch die Dateiplatzierung von WSL2

Legen Sie dasselbe Repository auf die Linux-Seite (~/repo) und auf die Windows-Seite (/mnt/c/repo), vergleichen Sie die Zeit von git status oder einem Entpacken, und der Unterschied aus Abschnitt 3.2 erscheint als Zahlen.

6.3. Hostseitiger Speicherzuwachs beim Start von Sandbox

Starten Sie Sandbox und beobachten Sie den Speicherzuwachs im Task-Manager des Hosts. Dass er weit kleiner bleibt, als „ein zweites vollständiges Windows“ vermuten ließe, ist die Wirkung des Teilens.

Um die hostseitige Speicheraufstellung weiter zu zerlegen, ist der Artikel zu den Sysinternals-Werkzeugen nützlich, der die Nutzung von RAMMap und VMMap zusammenfasst („Process Explorer / Handle / VMMap in der Praxis“).

Das sind jedoch Werkzeuge, um hostseitige Prozesse und physischen Speicher zu klassifizieren; sie beobachten das Teilen mit dem Gast selbst nicht direkt.

6.4. Unterschiede der Isolierungsmodi von Windows-Containern

Wenn Sie eine Umgebung für Windows-Container haben, starten Sie dasselbe Abbild mit docker run --isolation=process und mit --isolation=hyperv und vergleichen Sie Startzeit und das Bild im Task-Manager (unter Prozessisolierung erscheinen die Prozesse im Container in der Prozessliste des Hosts), um ein Gefühl dafür zu bekommen, wo die Isolierungslinie sitzt.⁷

Prozessisolierung setzt jedoch voraus, dass Host- und Abbildversion zusammenpassen, und auf einem Client-Betriebssystem ist sie auf Entwicklungs- und Testnutzung begrenzt. Hyper-V-Isolierung erlaubt eine breitere Kombination, daher führen Sie den Vergleich mit einem kompatiblen Paar durch.¹⁰

7. Drei Fehldeutungen, die Sie in der Praxis vermeiden sollten

7.1. „WSL2 ist langsam“

Langsam ist nicht WSL2, sondern der Datei-E/A-Pfad, der die Betriebssystemgrenze überquert. In vielen Fällen verwandelt allein das Verschieben des Projekts auf die Linux-Seite das Empfinden.⁴ Umgekehrt ist es aus demselben Grund nachteilig, Dateien, die Windows-Werkzeuge berühren, auf die Linux-Seite zu legen. Entscheiden Sie nach „auf dasselbe Betriebssystem legen wie das, was sie nutzt“.

7.2. „Dass vmmem groß wird, ist ein Speicherleck“

Der Speicher von WSL2 wächst und schrumpft mit der Nachfrage, und freigegebener Speicher wird zurückgegeben. Auf aktuellem WSL zieht autoMemoryReclaim (Voreinstellung dropCache) auch den Dateicache automatisch ein, sodass „es blieb groß“ sich oft mit der Zeit von selbst auflöst.⁵

Wenn es trotzdem bleibt, prüfen Sie, ob autoMemoryReclaim nicht disabled ist und ob pageReporting, das freigegebenen Speicher zurückgibt, nicht abgeschaltet wurde (und ob Sie nicht auf einem älteren WSL sind); setzen Sie dann entweder eine ausdrückliche Obergrenze mit memory in .wslconfig oder geben Sie am Ende einer Sitzung alles mit wsl --shutdown zurück.

Die Herangehensweise, ob es ein Leck ist, ist dieselbe wie in der Einführung der Speicherreihe, „Was bedeutet Windows’ „Speicherauslastung“ eigentlich?“.

7.3. „Es steckt in einem Container, also ist es sicher“

Prozessisolierte Container teilen den Kernel, und nach dem Maßstab von Microsoft sind sie keine Sicherheitsgrenze.⁸ Für das Ausführen nicht vertrauenswürdigen Codes oder von Proben wählen Sie Isolierung mit Hypervisor-Grenze: einen Hyper-V-isolierten Container, Windows Sandbox oder eine eigene VM.

Eine Hypervisor-Grenze ist jedoch kein universeller Freibrief.

Die Standardeinstellungen von Windows Sandbox haben Netzverbindung aktiviert, was eine nicht vertrauenswürdige App dem internen Netz aussetzen kann.¹ Wenn Sie sie zum Ausführen von Proben nutzen, verstärken Sie die Isolierung, indem Sie Netz und Zwischenablageumleitung in der .wsb-Konfigurationsdatei deaktivieren, oder nutzen Sie eine eigene VM in einem isolierten Netz.

8. Zusammenfassung — Abschluss der Reihe

Die Kernpunkte von Teil 3.

• Die Leichtigkeit leichter VMs ist das Ergebnis von „Verdopplung aufgeben“, nicht von „Isolierung schwächen“.
• WSL2 führt in einer verwalteten leichten Utility-VM einen echten Linux-Kernel aus, und Distributionen sind als Container in dieser VM isoliert.³ Die Leistungsregel ist, Dateien auf das Betriebssystem zu legen, das sie nutzt; Speicher wächst und schrumpft dynamisch, und .wslconfig steuert die Obergrenze.⁴⁵
• Windows Sandbox teilt die unveränderlichen Betriebssystemdateien des Hosts über das dynamische Basisabbild und die physischen Seiten der betreffenden Betriebssystembinärdateien über Direct Map, sodass es keine Kopie eines vollständigen Windows hält.² Die rund 500 MB veränderlicher Dateien und der Speicher der Apps, die Sie darin ausführen, werden weiterhin gesondert gebraucht.
• Der Isolierungsmodus von Containern wird beim Start gewählt, und die Seite, die sich Sicherheitsgrenze nennen darf, ist die Hyper-V-Isolierung.⁷⁸

Und die ganze Reihe auf eine Seite gebracht ergibt Folgendes.

• Teil 1: Unter Windows liegt eine Hypervisor-Schicht, und das Host-Betriebssystem selbst läuft als Root-Partition. Diese Schicht schlichtet CPU und Speicher (SLAT) unmittelbar, und die E/A synthetischer Geräte vermittelt die Root-Partition (VSP) jenseits von VMBus.
• Teil 2: Diese Schicht dient nicht nur dazu, VMs voneinander zu isolieren, sondern auch dazu, innerhalb desselben Betriebssystems eine Grenze stärker als der Kernel (VTL) zu ziehen. Die Standardsicherheit von Windows 11 baut darauf auf.
• Teil 3: Auf derselben Schicht macht das Schneiden der Verdopplung „eine virtuelle Maschine, die in Sekunden startet“ möglich. Die Isolierungslinie bleibt, und sie ist zum Alltagswerkzeug geworden.

flowchart TB
    accTitle: Die ganze Reihe in einem Bild
    accDescr: Der Hypervisor unmittelbar auf der Hardware ist Teil 1, die Trennung von VTL0 und VTL1 im Host-Windows ist Teil 2, und die Leichtigkeit von WSL2, Sandbox und Hyper-V-Isolierung auf derselben Schicht ist Teil 3, wobei prozessisolierte Container den Host-Kernel teilen, Sandbox durch Teilen und WSL2 durch einen zweckbestimmten Kernel leichter wird
    hw3["Hardware"] --> hv3["Hypervisor (Teil 1)"]
    hv3 --> rp3["Host-Windows (VTL-Trennung ist Teil 2)"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V-Isolierung (Teil 3)"]
    rp3 --> pc3["Prozessisolierter Container (geteilter Kernel)"]
    lw3 -.-> mech3["Sandbox erleichtert durch Teilen, WSL2 durch einen zweckbestimmten Kernel"]

Abbildung 15: Stapeln Sie die drei Folgen, und Sie haben das Gesamtbild dessen, was unter heutigem Windows liegt.

Virtualisierung ist keine Technik des Serverraums mehr und keine Technik nur für Leute, die VMs aufstellen. Unter Ihrem Windows stützt sie still sowohl Sicherheit als auch die Entwicklungserfahrung. Dort stehen wir jetzt.

Weiterführende Artikel

• Die Tiefen der Windows-Virtualisierung (Teil 1) — Wo läuft Ihr Windows eigentlich? Hypervisor und Partitionen
• Die Tiefen der Windows-Virtualisierung (Teil 2) — Speicher, den selbst der Kernel nicht sieht: Wie VBS, HVCI und Credential Guard funktionieren
• Die Tiefen des Windows-Speichers (Teil 3) — Abschnittsobjekte und Copy-on-Write
• Wie Sie mit Windows Sandbox die App-Validierung beschleunigen
• Registry-Umleitung und Virtualisierung unter Windows

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt das Einrichten von Entwicklungsumgebungen, die WSL2 und Container nutzen, den Entwurf von Validierungsumgebungen für Windows-Anwendungen sowie die Untersuchung von Leistung und Kompatibilität in virtualisierten Umgebungen.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Weiternutzung und Migration von Altbeständen
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ist WSL2 eine VM?

Ja. WSL2 führt in einer leichten Utility-VM einen echten Linux-Kernel aus, den Microsoft gebaut hat. Die VM verwaltet WSL im Hintergrund, sodass der Entwurf den Nutzer weder an VM-Einstellungen noch an Wartezeiten beim Start denken lässt. Jede Linux-Distribution läuft in dieser verwalteten VM als isolierter Container.

Warum sind Dateioperationen unter /mnt/c in WSL2 langsam?

Weil der Zugriff vom Linux-Kernel von WSL2 auf das Dateisystem der Windows-Seite über eine Dateifreigabe läuft, die die Betriebssystemgrenze überquert. Operationen auf dem Linux-Dateisystem (einer virtuellen ext4-Festplatte) sind schnell. Die Regel lautet daher, Projektdateien auf derselben Betriebssystemseite zu halten wie die Werkzeuge, die daran arbeiten.

Ist eine große Speichernutzung des vmmem-Prozesses ein Leck?

In den meisten Fällen nicht. Der Speicher von WSL2 wächst und schrumpft mit der Nutzung, und Speicher, den Prozesse freigegeben haben, wird unter der standardmäßig aktivierten Einstellung pageReporting an Windows zurückgegeben. Auch den Dateicache zieht aktuelles WSL über autoMemoryReclaim in .wslconfig automatisch ein (Voreinstellung dropCache). In Umgebungen, in denen diese Einstellungen deaktiviert wurden, oder auf älterem WSL kann der Speicher bis zum Beenden der VM bleiben; dann setzen Sie eine Obergrenze mit der Einstellung memory oder geben ihn mit wsl --shutdown zurück.

Wie kann Windows Sandbox ein vollständiges Windows von ein paar hundert Megabyte Datenträger starten?

Über einen Mechanismus namens dynamisches Basisabbild. Es teilt die unveränderlichen Betriebssystemdateien des bereits auf dem Host installierten Windows und hält eine saubere Kopie nur der wenigen veränderlichen Dateien. So entsteht ein vollständiges, startfähiges Abbild, ohne eine komplette Kopie von Windows zu speichern.

Sind Container sicherer als VMs?

Es hängt vom Isolierungsmodus ab. Prozessisolierte Container teilen den Kernel mit dem Host, und Microsoft betrachtet das nicht als robuste Sicherheitsgrenze. Wenn Sie gegnerischen Code behandeln, müssen Sie Hyper-V-Isolierung wählen, die jedem Container einen eigenen Kernel gibt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.