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

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

Beide ruhen auf demselben Windows-Hypervisor (Teil 1, „Wo läuft Ihr Windows eigentlich?“). In Teil 2 haben wir gesehen, dass diese Grundlage Isolierung stärker als der Kernel schaffen kann. Warum also ist das eine schwer und das andere leicht?

Die Frage, die die letzte Folge der Reihe beantwortet, ist nur eine.

Volle VMs sind schwer — warum sind WSL2 und Windows Sandbox so leicht?

Zielgruppe sind Entwickler und Betreiber, die WSL2, Windows Sandbox und Windows-Container für Entwicklung und Validierung nutzen und ihre Leichtigkeit und ihre Einschränkungen von den Mechanismen her verstehen wollen. Voraussetzungen sind Windows 10/11; das Durchgehen des Abschnitts Windows Sandbox verlangt eine Edition Pro, Enterprise oder Education (Home und Windows Server haben dieses Merkmal nicht). Hintergrundwissen ist der Begriff der Partitionen aus Teil 1. Die Schwierigkeit ist mittel.

1. Zuerst das Fazit

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

Die Quelle des Gewichts einer vollen VM ist nicht Isolierung selbst, sondern Verdopplung. Ein weiteres OS-Abbild auf dem Datenträger, eine weitere OS-Menge an Seiten im RAM und ein weiterer voller Boot jedes Mal, wenn Sie starten. Leichte VMs schneiden diese Verdopplung mit zwei Politiken: „teilen, was sicher zu teilen ist“ (Sandbox) und „wenn Sie es nicht teilen können, klein neu bauen“ (WSL2).

flowchart TB
    accTitle: Drei Arten des Teilens, die leichte VMs stützen
    accDescr: Das OS-Abbild, das eine volle VM früher verdoppelte, wird durch Teilen in Sandbox und durch Schrumpfen in WSL2 geschnitten; Speicher, der standardmäßig eine feste Zuteilung ist（dynamischer Speicher ist die Ausnahme）, wird zu dynamischem Leihen und Zurückgeben mit dem Host; der Start wird durch einen leichten Kernel und eine minimale Einrichtung ersetzt; nur die Isolierungsgrenze bleibt
    heavy["Volle VM: Verdopplung"] --> d1["Datenträger: OS-Abbildkopie"]
    heavy --> more{"Speicher oder Start?"}
    more --> d2["Speicher: feste Voreinstellung"]
    more --> d3["Start: voller Boot"]
    d1 -->|ersetzt durch| s1["Teilen（Sandbox）"]
    s1 -.-> s1b["oder schrumpfen（WSL2）"]
    d2 -->|ersetzt durch| s2["Dynamisches Leihen vom Host"]
    d3 -->|ersetzt durch| s3["Leichter Kernel + min."]

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

Unten schauen wir der Reihe nach auf WSL2, Windows Sandbox und Container und darauf, welche Art von Verdopplung jedes von ihnen schneidet.

2. Was eine volle VM trägt

Als Vergleichsgrundlinie hier, was eine herkömmliche VM trägt.

• Ein unabhängiges OS-Abbild. Sie hält jede Datei des Gast-Betriebssystems innerhalb einer virtuellen Festplatte. Selbst wenn der Host dasselbe Windows hat, teilt sie es nicht.
• Grobe Speicherzuteilung. Die Voreinstellung einer herkömmlichen VM ist, Host-Speicher in einer statischen Größe zuzuteilen. Mechanismen wie Hyper-V Dynamic Memory können die Zuteilung innerhalb eines konfigurierten Bereichs wachsen und schrumpfen lassen, aber die Mittel, sich an Nachfrageänderungen anzupassen, sind begrenzt.²
• Ein allgemeiner voller Boot. Firmware, der Bootloader und der Satz von Diensten starten in derselben Folge wie auf einem physischen Rechner.

flowchart TB
    accTitle: Die drei Lasten, die eine volle VM trägt
    accDescr: Eine volle VM trägt ein unabhängiges OS-Abbild, Speicherzuteilung, die standardmäßig statisch ist, und einen allgemeinen vollen Boot, und das zeigt sich als Kosten in Datenträger, RAM und Startzeit
    fullvm["Volle VM"] --> b1["Unabhängiges OS-Abbild"]
    fullvm --> more{"Speicher oder Boot?"}
    more --> b2["Statische Speichervoreinstellung"]
    more --> b3["Allgemeiner Boot"]
    b1 -.-> c1["Zusätzlicher Datenträger für eine Kopie"]
    b2 -.-> c2["Hält auch ungenutztes RAM"]
    b3 -.-> c3["Dauert zehn Sekunden"]

Abbildung 2: Die Aufschlüsselung der Kosten einer vollen VM wird nicht für Isolierung bezahlt, sondern für Allgemeinheit und Verdopplung.

Das sind keine Mängel; sie sind der Preis der Allgemeinheit, dass „Sie alles in den Gast legen können“. Für einen Einsatz wie das Ausführen eines alten Linux neben Windows Server ist diese Allgemeinheit der Wert. Aber für einen Einsatz wie „ich will dasselbe (oder ein festgelegtes) Betriebssystem wie der Host, jetzt, für Entwicklung oder Validierung ausführen“ ist das meiste verschwendetes Gepäck. Leichte VMs legen dieses Gepäck ab, indem sie den Zweck einengen.

3. WSL2 — Eine Utility-VM mit einem eigens gebauten Kernel

3.1. Struktur: Eine verwaltete VM und die Distributionen darin

WSL2 ist ein Mechanismus, der einen echten Linux-Kernel in einer leichten Utility-VM ausführt.³ Es gibt drei Punkte.

• Der Kernel ist echt, aber er ist ein Spezialprodukt. Es ist ein Linux-Kernel, den Microsoft aus dem Stable-Zweig baut, bereits in Größe und Leistung für WSL2 abgestimmt. Beim aktuellen Standard, dem über den Microsoft Store verteilten WSL, wird der Kernel zusammen mit dem WSL-Paket selbst aktualisiert und mit wsl --update angewendet (bei der älteren In-Box-Verteilung kam er über Windows Update).⁴ Weil er ein echter Kernel ist, ist die Systemaufrufkompatibilität vollständig, und Werkzeuge wie Docker laufen, wie sie sind.
• Die VM ist hinter den Kulissen. Anlegen, Starten und Stoppen der VM verwaltet WSL; der Nutzer öffnet nur eine Shell. Es gibt keinen VM-Einstellungsbildschirm und kein gefühltes Warten auf einen Boot.⁴
• Eine Distribution ist ein Container innerhalb der VM. Distributionen wie Ubuntu und Debian laufen als isolierte Container innerhalb einer verwalteten VM. Sie teilen den Netz-Namespace und den Kernel, während Namespaces wie PID, Mount und Benutzer getrennt sind.³

flowchart TB
    accTitle: WSL2-Architektur
    accDescr: Ein Host-Windows und eine leichte Utility-VM sitzen nebeneinander auf dem Hypervisor; ein von Microsoft gebauter Linux-Kernel läuft innerhalb der VM; und jede Distribution läuft als isolierter Container darin
    hv["Hypervisor"] --> host["Host-Windows"]
    hv --> uvm["Leichte Utility-VM"]
    uvm --> lk["Linux-Kernel（Microsoft-Build; aktualisiert 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?“ ist „ja, aber eine verwaltete, hinter-den-Kulissen-VM“, und selbst wenn Sie mehrere Distributionen installieren, gibt es immer noch eine VM.

In dem Moment, in dem Sie wsl tippen, sieht die Rückseite so aus.

flowchart TB
    accTitle: Vom Ausführen des wsl-Befehls bis eine Shell in wenigen Sekunden zurückkehrt
    accDescr: Läuft die Utility-VM beim Ausführen von wsl nicht, starten die leichte VM und der Linux-Kernel; läuft sie bereits, werden sie wiederverwendet; und eine Shell kehrt im Container der Distribution 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 bereits laufende VM wiederverwenden"]
    bootvm --> shell["Eine Shell kehrt im Container zurück"]
    reuse --> shell

Abbildung 4: Das Warten ist nur ein minimaler VM-Start, und hier zeigt sich das Ablegen des Gepäcks eines vollen Boots.

3.2. Datei-I/O: Auf welcher Seite Sie es ablegen, macht es zu einer anderen Sache

Das Thema, das in Gesprächen über WSL2-Leistung immer kommt, ist, wo Sie die Dateien ablegen.

• Operationen auf Dateien auf der Linux-Seite (der ext4-virtuellen Festplatte) sind schnell. Das liegt daran, dass der Linux-Kernel mit seinem eigenen Dateisystem direkt spricht, und Beschleunigungen von bis zu 20× gegenüber WSL1 für Tarball-Extraktion sowie 2–5× für git clone und npm install sind berichtet worden.⁴
• Operationen auf Dateien auf der Windows-Seite (/mnt/c und Ähnliches) werden langsam, weil sie über Dateifreigabe gehen, die eine OS-Grenze überquert. Dateisystemleistung über OS-Grenzen hinweg ist der eine große Punkt, in dem WSL2 schlechter ist als WSL1.⁴

Also lautet die Regel: „legen Sie Projektdateien auf dieselbe OS-Seite wie die Werkzeuge, die sie bedienen“.⁴ Ein Repository, das Sie mit Linux-Build-Werkzeugen behandeln, kommt auf die Linux-Seite; eine Lösung, die Sie in Visual Studio bauen, kommt auf die Windows-Seite.

flowchart TB
    accTitle: Die Gabelung der WSL2-Datei-I/O-Pfade
    accDescr: Zugriff auf die ext4-virtuelle Festplatte der Linux-Seite ist direkt vom Linux-Kernel und daher schnell; Zugriff auf Dateien der Windows-Seite geht über Freigabe, die eine OS-Grenze überquert, und ist daher langsam
    io["Dateioperationen innerhalb von WSL2"] --> place{"Auf welcher Seite liegt die Datei?"}
    place -->|"Linux-Seite（home usw.）"| ext4["Direktes I/O zur ext4-virtuellen Festplatte"]
    place -->|"Windows-Seite（/mnt/c usw.）"| p9["Über Freigabe, die eine OS-Grenze überquert"]
    ext4 --> fast["Schnell（Beispiele bis 20× vs. WSL1）"]
    p9 --> slow["Neigt dazu, langsam zu sein"]
    slow -.-> fix["Fix: Datei auf das OS legen, das sie nutzt"]

Abbildung 5: Was langsam ist, ist der Pfad, nicht WSL2, also lässt das Ändern, wo Sie die Dateien ablegen, das Leistungsproblem oft verschwinden.

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

Die Speichernutzung von WSL2 (Sie sehen sie als vmmem-Prozess im Task-Manager) ist keine feste Reservierung; sie wächst und schrumpft mit der Nutzung. Speicher, den Prozesse freigegeben haben, wird unter der Einstellung pageReporting, die standardmäßig aktiviert ist, automatisch an Windows zurückgegeben.⁵ Seiten, die als Dateicache gehalten wurden, kehrten früher nicht an Windows zurück, bis die VM beendet wurde.⁴ In aktuellem WSL zieht die experimentelle .wslconfig-Einstellung autoMemoryReclaim (die Voreinstellung ist dropCache) den Cache ebenfalls 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 Host-Speicher belasten.

flowchart TB
    accTitle: Wie WSL2-Speicher wächst, schrumpft und zurückgegeben wird
    accDescr: Nachfragewachstum innerhalb von WSL2 hebt die Speichernutzung der VM; von Prozessen freigegebene Seiten werden unter pageReporting, das standardmäßig aktiviert ist, an Windows zurückgegeben; Dateicache zieht autoMemoryReclaim standardmäßig automatisch ein; aber bei deaktivierter Einstellung oder älterem WSL bleibt er bis zum Beenden der VM, und wsl --shutdown gibt alles zurück
    grow["Speichernachfrage wächst innerhalb von WSL2"] --> vm["vmmem-Nutzung wächst"]
    vm --> freed{"Ist diese Seite freigegeben worden?"}
    freed -->|"Freigegeben（pageReporting）"| ret["Zurück an Windows"]
    freed -->|Als Dateicache gehalten| amr["autoMemoryReclaim（Standard）"]
    amr -.-> old2["Bleibt bis VM-Ende (altes WSL)"]
    old2 --> sd["wsl --shutdown gibt alles zurück"]

Abbildung 6: Was wie „es ist nur gewachsen“ aussieht, ist hauptsächlich der Cache (und, wenn pageReporting aus ist, auch von Prozessen freigegebene Seiten), also kennen Sie den Rückgabepfad, bevor Sie entscheiden, es sei ein Leck.

Wenn Sie eine ausdrückliche Obergrenze wollen, kann %UserProfile%\.wslconfig den Gesamtspeicher der VM, die CPU-Zahl und Swap steuern.⁵

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

Nach dem Ändern der Einstellungen starten Sie die VM mit wsl --shutdown neu, damit sie greifen. Diese dynamische Zuteilung — „die Obergrenze ist eine Einstellung, die tatsächliche Nutzung folgt der Nachfrage“ — wird im nächsten Thema, Windows Sandbox, noch weiter getrieben.

4. Windows Sandbox — Das Windows des Hosts wiederverwenden

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

Windows Sandbox ist ein wegwerfbarer Windows-Desktop, isoliert durch den Hypervisor. Schließen Sie ihn, verschwindet alles; das nächste Mal startet er in wenigen Sekunden aus einem sauberen Zustand.¹

Das erste Rätsel ist der Datenträger. Er kann ein vollständiges Windows booten, und doch ist das Basisabbild von Sandbox nach der Installation nur etwa 500 MB und bei der Verteilung 30 MB komprimiert.² Das Geheimnis ist das dynamische Basisabbild.

• Die meisten OS-Dateien sind unveränderlich, sodass die Kopien des Hosts unverändert geteilt werden können.
• Die kleine Zahl veränderlicher Dateien kann nicht geteilt werden, also wird eine saubere Kopie davon innerhalb des Basisabbilds gehalten.
• Beim Start werden die unveränderlichen Dateien des Hosts plus die lokalen Kopien der veränderlichen Dateien kombiniert, um ein vollständiges Windows-Abbild zusammenzubauen.²

Mit anderen Worten lädt Sandbox weder eine Kopie von Windows herunter noch speichert sie eine; es verwendet das bereits auf dem Host installierte Windows wieder, um zu starten.

flowchart TB
    accTitle: Wie ein dynamisches Basisabbild zusammengebaut wird
    accDescr: Unveränderliche OS-Dateien aus dem Host-Windows werden geteilt; nur veränderliche Dateien werden als saubere Kopie im Basisabbild gehalten; und die zwei werden kombiniert, um das vollständige Windows-Abbild von Sandbox zusammenzubauen
    hostw["Das vollständige Windows des Hosts"] --> imm["Unveränderliche OS-Dateien（die Mehrheit）"]
    hostw --> mut["Veränderliche OS-Dateien（eine Minderheit）"]
    imm -->|Unverändert geteilt| img["Sandbox-Bootabbild"]
    mut -->|Eine saubere Kopie halten| img
    img --> boot["Bootet als vollständiges Windows"]
    img -.-> size["Nur etwa 500 MB müssen gespeichert werden"]

Abbildung 7: Die Form, Datenträgerverdopplung aufzugeben, ist nicht „ein weiteres Windows besitzen“, sondern „es aus dem Windows des Hosts zusammenbauen“.

Diese Zusammensetzung macht den folgenden Lebenszyklus möglich. Was verworfen wird, ist der lokale Zustand innerhalb der Sandbox. Haben Sie im .wsb-Konfigurationsdatei einen beschreibbaren Ordner vom Host zugeordnet, bleiben Änderungen dort auf dem Host.⁶

flowchart TB
    accTitle: Der Lebenszyklus von Windows Sandbox
    accDescr: Starten bereitet in wenigen Sekunden ein sauberes Windows vor; nach App-Validierung oder Experimenten schließen Sie es und der ganze Zustand innerhalb der Sandbox wird verworfen, sodass das nächste Mal ebenfalls sauber startet; aber Änderungen an einem als beschreibbar zugeordneten Host-Ordner bleiben
    launch["Start（wenige Sekunden）"] --> clean["Ein sauberes Windows"]
    clean --> work["App-Validierung oder Experimente"]
    work --> close2["Schließen"]
    close2 --> discard["Den ganzen Zustand innerhalb der Sandbox verwerfen"]
    discard -.-> mapped["Änderungen in einem zugeordneten beschreibbaren Ordner bleiben auf dem Host"]
    discard -->|Nächster Start| launch

Abbildung 8: Jedes Mal zu sauber zurückkehren zu können liegt daran, dass der veränderliche Teil eine wegwerfbare Kopie ist, und das Verwerfen Teil des Entwurfs ist.

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

Nicht nur der Datenträger, sondern auch RAM wird geteilt. Weil Sandbox dasselbe OS-Abbild wie der Host ausführt, wird eine Technik namens „Direct Map“ genutzt, sodass sie für OS-Binärdateien dieselben physischen Speicherseiten wie der Host nutzt. Wenn ntdll.dll innerhalb der Sandbox in den Speicher geladen wird, zeigt sie auf dieselbe physische Seite wie dieselbe bereits auf dem Host geladene Binärdatei. Ohne die Geheimnisse des Hosts in Gefahr zu bringen, erreicht sie einen viel kleineren Speicherfußabdruck als eine herkömmliche VM.²

„Dieselbe physische Seite unter mehreren Nutzern teilen“ — das ist dieselbe Idee wie das Teilen von DLLs über Section-Objekte, dem wir in Teil 3 der Speicherreihe gefolgt sind („Section Objects and Copy-on-Write“). Dieser Mechanismus war Teilen zwischen Prozessen; Sandbox tut es über eine VM-Grenze hinweg.

flowchart TB
    accTitle: Teilen physischer Seiten über Direct Map
    accDescr: Eine App auf dem Host und eine App innerhalb der Sandbox teilen dieselbe physische Speicherseite für OS-Binärdateien wie ntdll und senken so die Speichernutzung
    happ["Eine App auf dem Host"] --> hva["Virtuelle Adresse der Host-Seite"]
    sapp["Eine App innerhalb der Sandbox"] --> sva["Virtuelle Adresse der Sandbox-Seite"]
    hva --> phys["Dieselbe physische Seite（OS-Binärdateien wie ntdll.dll）"]
    sva --> phys
    phys -.-> save["Keine Verdopplung des OS-Anteils an RAM nötig"]

Abbildung 9: Direct Map ist die Idee des Seitenteilens, die zwischen Prozessen genutzt wurde, angewendet über eine VM-Grenze hinweg.

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

Gegenüber der statischen Speicherzuteilung einer herkömmlichen VM entscheidet die Containertechnik, auf der Sandbox sitzt, die Ressourcenzuteilung dynamisch in Zusammenarbeit mit dem Host. Wird dem Host der Speicher knapp, kann er Speicher vom Container zurückholen, genauso wie er ihn von einem gewöhnlichen Prozess zurückholt.² Hyper-V Dynamic Memory lässt die Zuteilung einer VM ebenfalls innerhalb eines konfigurierten Bereichs wachsen und schrumpfen, aber Sandbox geht weiter: Der Unterschied ist, dass es auf demselben Feld leiht und zurückgibt wie die Speicherverwaltung des Hosts.

flowchart TB
    accTitle: Speicherzusammenarbeit zwischen Host und Sandbox
    accDescr: Die Voreinstellung einer herkömmlichen VM ist eine ausschließliche Zuteilung fester Größe mit begrenzten Anpassungsmitteln; Sandbox wird zum Rückholziel bei Host-Speicherdruck und leiht und gibt Speicher auf demselben Feld wie gewöhnliche Prozesse
    pressure["Host-Speicherdruck steigt"] --> from{"Wo holen wir zurück?"}
    from --> proc["Working Sets gewöhnlicher Prozesse"]
    from --> sbx["Die Nutzung der Sandbox（des Containers）"]
    proc --> relief["Freier Speicher wird gesichert"]
    sbx --> relief
    relief -.-> contrast["Eine herkömmliche VM hat begrenzte Anpassungsmittel"]

Abbildung 10: Beim Leihen und Zurückgeben von Speicher steht Sandbox auf der Prozessseite statt auf der VM-Seite und bietet Speicher an, wenn der Host in Not ist.

In Teil 1 haben wir gesagt „die Leistung einer VM hängt auch von der Host-Seite ab“, aber bei leichten VMs gehen wir einen Schritt weiter: die Zuteilung von Speicher selbst ist eine gemeinsame Aufgabe mit dem Host. Der Grund, warum Sandbox mit dem Gefühl „eine weitere App“ statt „ein schweres Virtualisierungsprodukt“ genutzt werden kann, ist diese Zusammenarbeit.

Das konkrete Verfahren, Sandbox zur Validierung einer Geschäftsanwendung zu nutzen, behandelt der frühere Artikel „Wie Sie mit Windows Sandbox die App-Validierung beschleunigen“. Dieser Artikel ist der Mechanismus darunter.

5. Container — Wo Sie die Isolierungslinie ziehen

5.1. Prozessisolierung und Hyper-V-Isolierung

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

• Prozessisolierung: mehrere Container teilen den Kernel mit dem Host und isolieren durch Namespace-Virtualisierung von Dateisystem, Registry, Netzports, Prozess-ID-Raum, Object-Manager-Namensraum und so weiter. Es ist im Wesentlichen derselbe Ansatz wie Linux-Container.
• Hyper-V-Isolierung: jeder Container läuft innerhalb einer hochoptimierten VM und hat was faktisch ein eigener Kernel ist. Das Vorhandensein der VM legt Hardware-Isolierung zwischen die Container und den Host.⁷

Isolierung über Namespaces lässt sich als gründliche Version der Technik beschreiben, die wir im Artikel zur Registry-Virtualisierung gesehen haben („Registry-32-Bit/64-Bit-Umleitung und Virtualisierungsfallen“) — „unter derselben API eine andere Wirklichkeit zeigen“.

flowchart TB
    accTitle: Prozessisolierung gegenüber Hyper-V-Isolierung
    accDescr: Unter Prozessisolierung teilen Container den Kernel mit dem Host und isolieren über Namespaces; unter Hyper-V-Isolierung hat jeder Container einen eigenen Kernel innerhalb 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 ist, ob Sie die Isolierungslinie über dem Kernel ziehen oder den Kernel selbst teilen, eine Wahl, die Sie beim Start treffen.

5.2. Welches können Sie eine „Sicherheitsgrenze“ nennen

Der Unterschied zwischen diesen zwei Modi ist nicht nur eine Leistungsgeschichte. Microsoft betrachtet einen prozessisolierten Container nicht als robuste Sicherheitsgrenze. Die Container, die (mit Schwachstellenreaktion) als Sicherheitsgrenze gepflegt werden, sind hypervisor-isolierte Container, und Hyper-V-Isolierung ist das, was Sie in einem gegnerischen Multi-Tenant-Szenario wählen sollten.⁸

Das VBS, das wir in Teil 2 gesehen haben, war ebenfalls ein Entwurf, der „der Kernel kann durchbrochen werden“ annimmt und sich auf eine Hypervisor-Grenze zurückzieht. Dasselbe Kriterium gilt in der Welt der Container. Die Linie, die nicht vertrauenswürdigen Code einsperrt, wird an der Hypervisor-Grenze gezogen, nicht auf der Innenseite eines geteilten Kernels.

flowchart TB
    accTitle: Wie Sie Isolierung danach wählen, wie sehr Sie dem Code vertrauen
    accDescr: Ist die Arbeitslast vertrauenswürdig, nehmen Sie Dichte und Leistung mit Prozessisolierung; ist der Code nicht vertrauenswürdig oder der eines anderen, wählen Sie eine Hypervisor-Grenze wie einen Hyper-V-isolierten Container, eine gehärtete Windows Sandbox mit deaktiviertem Netz oder eine isolierte VM
    trust{"Können Sie diesem Code vertrauen?"} -->|Ja| dens["Prozessisolierung（Dichte und Tempo zuerst）"]
    trust -->|Nein / Code eines anderen| bound["Eine Hypervisor-Grenze wählen"]
    bound --> opt1["Hyper-V-isolierte Container"]
    bound --> opt2["Eine gehärtete Sandbox oder eine isolierte VM"]

Abbildung 12: Isolierungsmodus ist eine Sicherheitsgeschichte, bevor er eine Leistungsgeschichte ist, und Vertrauen entscheidet, wo Sie die Linie ziehen.

Nebenbei: Einen Hyper-V-isolierten Container innerhalb einer Hyper-V-VM auszuführen macht den Hypervisor zwei Schichten tief — verschachtelte Virtualisierung. Eine Ebene der Verschachtelung ist in Produktion auf Umgebungen unterstützt, die die Bedingungen erfüllen (ein Intel-Prozessor mit einem Host Windows 10 / Windows Server 2016 oder später, oder ein AMD-Prozessor mit einem Host Windows 11 / Windows Server 2022 oder später, und jeweils die entsprechende VM-Konfigurationsversion), und eine weitere Voraussetzung ist eine Einstellung, die der äußeren VM Virtualisierungserweiterungen zeigt (ExposeVirtualizationExtensions auf Set-VMProcessor in Hyper-V). WSL2 innerhalb einer VM auszuführen ist auf dieselbe Weise unterstützt.⁹ Ob Sie WSL2 oder Docker in einer Entwicklungs-VM in der Cloud nutzen können, entscheidet ebenfalls, ob diese VM-Größe und -Konfiguration verschachtelte Virtualisierung zeigen.

flowchart TB
    accTitle: Die Struktur verschachtelter Virtualisierung
    accDescr: Eine Cloud-VM sitzt auf dem Hypervisor des physischen Hosts, und darin läuft ein weiterer Hypervisor（unterstützte Verschachtelung ist eine Ebene）, um WSL2 und Hyper-V-isolierte Container zu stützen
    phys3["Der Hypervisor des physischen Hosts"] --> cvm["Cloud-VM（Entwicklungsrechner）"]
    cvm --> nhv["Hypervisor innerhalb der VM（Verschachtelungsebene 1）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V-isolierter Container"]
    nhv -.-> limit["Unterstützte Verschachtelung ist eine Ebene"]

Abbildung 13: Der Grund, warum wsl innerhalb einer Cloud-VM läuft, ist, dass verschachtelte Virtualisierung offiziell nur für eine Ebene unterstützt wird.

5.3. Das Spektrum von Isolierung und Leichtigkeit

Die Besetzung bisher auf einer einzigen Achse aufzureihen sieht so aus.

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, WSL2 durch einen eigens gebauten Kernel）; eine volle VM ist am schwersten, aber allgemein
    ax["Leicht ← → Schwer"] ~~~ p1
    p1["Prozessisolierte Container（geteilter Kernel）"] --> p2["WSL2, Sandbox, Hyper-V-Isolierung（leichte VMs mit eigenem Kernel）"]
    p2 --> p3["Volle VM（führt alles aus; hält eine vollständige Kopie）"]
    p1 -.-> n1["Grenze: Namespaces"]
    p2 -.-> n2["Grenze: Hypervisor"]
    p3 -.-> n3["Grenze: Hypervisor + vollständige Unabhängigkeit"]

Abbildung 14: Die Gruppe der leichten VMs ist die mittlere Lösung, die die Hypervisor-Grenze behielt und Verdopplung schnitt; die Art, wie sie sie schneiden, teilt sich in Teilen für Sandbox und einen eigens gebauten Kernel für WSL2.

6. Selbst nachsehen

Leichtigkeit und Teilen sind Dinge, die Sie auf einem Rechner vor sich beobachten können.

Startzeit und das Steigen und Fallen von Speicher (WSL2). Mit geöffnetem Task-Manager versuchen Sie das Folgende.

# 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

Tun Sie einen großen Build oder eine Dateioperation innerhalb von WSL2, wächst vmmem, und Sie können beobachten, wie er mit wsl --shutdown auf einmal zurückgegeben wird.

Der Geschwindigkeitsunterschied danach, wo Sie die Dateien ablegen (WSL2). Legen Sie dasselbe Repository auf die Linux-Seite (~/repo) und auf die Windows-Seite (/mnt/c/repo) und vergleichen Sie die Zeit für git status oder eine Extraktion, und der Unterschied aus Abschnitt 3.2 zeigt sich in Zahlen.

Hintergrund für Direct Map (Sandbox). Starten Sie Sandbox und schauen Sie auf den Zuwachs an Speicher im Task-Manager auf dem Host. Dass der Zuwachs weit kleiner bleibt, als „ein weiteres Windows“ Sie erwarten ließe, ist die Wirkung des Teilens, die ihre Geschichte erzählt. Um die Speicheraufschlüsselung der Host-Seite weiter zu graben, ist der Artikel zu den Sysinternals-Werkzeugen, der die Nutzung von RAMMap und VMMap behandelt („Process Explorer / Handle / VMMap in der Praxis“), nützlich. Das sind jedoch Werkzeuge, um die Klassifikation von Prozessen und physischem Speicher auf der Host-Seite zu betrachten; sie beobachten das Teilen mit dem Gast selbst nicht direkt.

Container-Isolierungsmodi (Docker / Windows-Container). Haben Sie eine Windows-Container-Umgebung, starten Sie dasselbe Abbild mit docker run --isolation=process und --isolation=hyperv und vergleichen Sie Startzeit und wie es im Task-Manager aussieht (unter Prozessisolierung erscheinen Prozesse innerhalb des Containers in der Prozessliste des Hosts), und Sie können fühlen, wo die Isolierungslinie sitzt.⁷ Prozessisolierung setzt jedoch voraus, dass Host und Abbildversionen zusammenpassen, und auf einem Client-OS ist sie auf Entwicklungs- und Testnutzung begrenzt. Hyper-V-Isolierung erlaubt einen weiteren Satz von Kombinationen, also tun Sie den Vergleich auf einem kompatiblen Paar.¹⁰

7. Drei Fehldeutungen, die Sie in der Praxis vermeiden

7.1. „WSL2 ist langsam“

Was langsam ist, ist nicht WSL2, sondern der Datei-I/O-Pfad, der eine OS-Grenze überquert. Es gibt viele Fälle, in denen allein das Verschieben des Projekts auf die Linux-Seite das Gefühl zu einer anderen Sache macht.⁴ Umgekehrt ist das Ablegen von Dateien, die Windows-Werkzeuge berühren werden, auf der Linux-Seite aus demselben Grund ebenso ungünstig. Beurteilen Sie nach „legen Sie es auf dasselbe OS wie die Seite, die es nutzt“.

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

WSL2-Speicher wächst und schrumpft mit der Nachfrage, und freigegebene Anteile werden zurückgegeben. Auf aktuellem WSL zieht autoMemoryReclaim (die Voreinstellung ist dropCache) Dateicache ebenfalls automatisch ein, sodass „es blieb groß“ sich oft mit der Zeit auflöst.⁵ Bleibt es trotzdem, bestätigen Sie, dass autoMemoryReclaim nicht auf disabled gesetzt wurde und dass pageReporting, das für die Rückgabe freigegebener Anteile zuständig ist, nicht ausgeschaltet wurde (oder dass Sie nicht auf älterem WSL sind), dann machen Sie entweder die Obergrenze mit memory in .wslconfig ausdrücklich oder geben Sie alles mit wsl --shutdown an einer Sitzungsgrenze zurück. Die Denkweise, ein Leck von keinem Leck zu unterscheiden, ist dieselbe wie in der Einführungsfolge der Speicherreihe, „Was bedeutet Windows’ „Speicherauslastung“ eigentlich?“.

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

Ein prozessisolierter Container teilt den Kernel, und nach Microsofts Kriterium ist er keine Sicherheitsgrenze.⁸ Zum Ausführen nicht vertrauenswürdigen Codes oder eines Exemplars wählen Sie Isolierung, die eine Hypervisor-Grenze hat, etwa einen Hyper-V-isolierten Container, Windows Sandbox oder eine eigene VM. Eine Hypervisor-Grenze ist jedoch keine pauschale Freistellung. Die Standardeinstellungen von Windows Sandbox haben Netzkonnektivität aktiviert und können eine nicht vertrauenswürdige App dem internen Netz aussetzen.¹ Nutzen Sie sie zum Ausführen eines Exemplars, 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 — Die Reihe schließen

Die Punkte von Teil 3.

• Die Leichtigkeit einer leichten VM ist das Ergebnis von „Verdopplung stoppen“, nicht von „Isolierung schwächen“.
• WSL2 führt einen echten Linux-Kernel in einer verwalteten leichten Utility-VM aus, und Distributionen sind als Container innerhalb dieser VM isoliert.³ Die Leistungsregel ist, Dateien auf das OS zu legen, das sie nutzt, und Speicher wächst und schrumpft dynamisch, wobei die Obergrenze in .wslconfig steuerbar ist.⁴⁵
• Windows Sandbox teilt die unveränderlichen OS-Dateien des Hosts über ein dynamisches Basisabbild und teilt auch die physischen Seiten der Ziel-OS-Binärdateien über Direct Map, sodass sie keine Kopie eines vollständigen Windows hält.² Sie brauchen trotzdem etwa 500 MB für die veränderlichen Dateien plus den Speicher der Apps, die Sie darin ausführen.
• Der Isolierungsmodus von Containern wird beim Start gewählt, und die Seite, die Sie eine Sicherheitsgrenze nennen können, ist Hyper-V-Isolierung.⁷⁸

Und legen wir die ganze Reihe auf eine Seite, sieht es so aus.

• Teil 1: Es gibt eine Hypervisor-Schicht unter Windows, und das Host-Betriebssystem selbst läuft als Root-Partition. Schlichtung von CPU und Speicher (SLAT) geschieht direkt durch diese Schicht, und I/O synthetischer Geräte vermittelt die Root-Partition (VSP) jenseits des VMBus.
• Teil 2: Diese Schicht wird nicht nur genutzt, um VMs voneinander zu isolieren, sondern auch, um 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 von Verdopplung „eine virtuelle Maschine, die in Sekunden startet“ möglich. Die Isolierungslinie bleibt, und sie ist zu einem Alltagswerkzeug geworden.

flowchart TB
    accTitle: Ein Bild der ganzen Reihe
    accDescr: Der Hypervisor direkt auf der Hardware ist Teil 1; die Teilung von VTL0 und VTL1 innerhalb des Host-Windows ist Teil 2; die Leichtigkeit von WSL2, Sandbox und Hyper-V-Isolierung auf derselben Schicht ist Teil 3; prozessisolierte Container teilen den Host-Kernel; Sandbox erleichtert durch Teilen, WSL2 durch einen eigens gebauten Kernel
    hw3["Hardware"] --> hv3["Hypervisor（Teil 1）"]
    hv3 --> rp3["Host-Windows（VTL-Isolierung ist Teil 2）"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V-Isolierung（Teil 3）"]
    rp3 --> pc3["Prozessisolierte Container（geteilter Kernel）"]
    lw3 -.-> mech3["Sandbox teilt; WSL2 erleichtert mit einem eigens gebauten Kernel"]

Abbildung 15: Stapeln Sie die drei Folgen, und Sie haben das Gesamtbild des Grunds unter aktuellem Windows.

Virtualisierung ist keine Technik des Serverraums mehr und keine Technik nur für Leute, die VMs aufstellen. Am Grund 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
• The Depths of Windows Memory (Part 3) — Section Objects and Copy-on-Write: What DLLs and File Mappings Really Are
• Wie Sie mit Windows Sandbox die App-Validierung beschleunigen
• Registry-32-Bit/64-Bit-Umleitung und Virtualisierungsfallen — Wow6432Node und das Problem „Der Wert, den ich geschrieben habe, ist nicht da“

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt das Einrichten von Entwicklungsumgebungen, die WSL2 und Container nutzen, den Entwurf von Validierungsumgebungen für Windows-Apps 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 einen echten Linux-Kernel, den Microsoft baut, in einer leichten Utility-VM aus. Die VM wird von WSL hinter den Kulissen verwaltet, sodass der Entwurf den Nutzer nie an VM-Einstellungen oder das Warten auf einen Boot denken lässt. Jede Linux-Distribution läuft als isolierter Container innerhalb dieser verwalteten VM.

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

Weil Zugriff vom WSL2-Linux-Kernel auf das Dateisystem der Windows-Seite über Dateifreigabe geht, die eine OS-Grenze überquert. Operationen auf dem Linux-Dateisystem (einer ext4-virtuellen Festplatte) sind schnell, also lautet die Regel, Projektdateien auf derselben OS-Seite zu halten wie die Werkzeuge, die daran arbeiten.

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

In den meisten Fällen ist es kein Leck. WSL2-Speicher wächst und schrumpft mit der Nutzung, und Speicher, den Prozesse freigegeben haben, wird unter der Einstellung pageReporting, die standardmäßig aktiviert ist, an Windows zurückgegeben. Auch Dateicache-Seiten zieht aktuelles WSL über autoMemoryReclaim in .wslconfig automatisch ein (die Voreinstellung ist dropCache). In Umgebungen, in denen diese Einstellungen deaktiviert wurden, oder auf älterem WSL kann der Speicher bis zum Beenden der VM bleiben; in dem Fall 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 booten?

Über einen Mechanismus namens dynamisches Basisabbild. Es teilt die unveränderlichen OS-Dateien aus dem bereits auf dem Host installierten Windows und hält eine saubere Kopie nur der kleinen Zahl veränderlicher Dateien. So kann es ein vollständiges, bootfähiges Abbild zusammenbauen, ohne eine volle 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, brauchen Sie Hyper-V-Isolierung, 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.