Ist WSL2 nicht einfach nur eine VM?

 (ssg.dev)
9 Punkte von GN⁺ 2025-12-02 | 3 Kommentare | Auf WhatsApp teilen
  • Die Subsystemstruktur von Windows NT ist als API-Aufrufkonvertierungsschicht aufgebaut, um Programme für andere Betriebssysteme auszuführen
  • WSL1 setzt diese Tradition fort und arbeitet als leichte Übersetzungsschicht, die Linux-Aufrufe in Windows-Kernelaufrufe umwandelt
  • WSL2 wurde wegen Performance-Problemen auf eine vollständige Linux-VM auf Hyper-V-Basis umgestellt und führt einen echten Linux-Kernel aus
  • WSL2 bietet mit dynamischem Speichermanagement, Windows-Laufwerks-Mount, GUI-Integration über WSLg und ähnlichem eine höhere Integration als eine normale VM
  • Obwohl es Einschränkungen wie unbequeme Dateiverwaltung und Datenträger-Image-Abhängigkeit gibt, ist die selektive Nutzung der jeweiligen Vor- und Nachteile von WSL1 und WSL2 entscheidend

Das Subsystem-Konzept von Windows NT

  • Das Subsystem (subsystem) von Windows NT bezeichnet einen Satz aus APIs und einer Aufrufkonvertierungsschicht, um Programme für andere Betriebssysteme auszuführen
    • In früheren NT-Versionen existierten u. a. OS/2-Subsystem (OS2SS.EXE), POSIX-Subsystem (PSXSS.EXE) usw.
    • CSRSS.EXE ist die Win32-API-Übersetzungsschicht; einige Funktionen wurden in den Kernel-Modus (WIN32K.SYS) verschoben
  • Das POSIX-Subsystem war eine Minimalimplementierung für staatliche Zertifizierungsanforderungen und wurde später durch das auf Interix basierende Windows Services for Unix ersetzt

WSL1: Übersetzungsbasierte Linux-Schicht

  • Das WSL1 (Windows Subsystem for Linux) ist eine dünne Übersetzungsschicht, die Linux-Systemaufrufe in Windows-Aufrufe konvertiert
    • Beim Start nutzt nur der bash-Prozess wenige MB Speicher und wird im Task-Manager als normaler Prozess angezeigt
    • Das Root-Dateisystem liegt als einzelne Dateistruktur auf NTFS, sodass der Speicher-Overhead nahezu nicht existiert
  • Einschränkungen
    • Eingeschränkte I/O-Leistung: Übersetzungskosten durch Unterschiede zwischen Linux- und Win32-Dateisystem-APIs
    • Für die Ausführung der GUI ist ein externer X-Server erforderlich (z. B. X410)
    • Keine Unterstützung für Raw-Sockets, daher sind traceroute, nmap, tcpdump usw. nicht ausführbar

WSL2: Linux-VM auf Hyper-V-Basis

  • Auf Nutzeranforderung hat Microsoft eine vollständige Linux-VM auf Hyper-V eingeführt
    • Das Root-Dateisystem wird als einzelne VHDX-Datei verwaltet
    • Über den Befehl wsl --set-version "Ubuntu" 2 ist ein Wechsel zwischen WSL1 und WSL2 möglich
  • Leistungseigenschaften
    • Der Startvorgang ist anfangs langsamer, jedoch wird ein nativ Linux-Kernel ausgeführt
    • Die Speichernutzung ist dynamisch und kann bis zu 50 % des physischen Maximalspeichers ansteigen
    • Im stress-Test steigt der Speicherverbrauch mit der Last und wird anschließend automatisch reduziert
    • Bei Bedarf kann die VM mit dem Befehl wsl --shutdown beendet werden

Integration und Grenzen von WSL2

  • WSL2 stärkt im Vergleich zu traditionellen VMs die Integration mit Windows
    • Automatisches Mounten von Windows-Laufwerken, Zugriff auf Linux-Laufwerke über den Pfad \\wsl$\\, GUI-App-Ausführung über WSLg
    • GUI-Apps werden über Remote-Desktop-Protokoll gestreamt; für DPI und Textskalierung sind separate Einstellungen erforderlich
  • Dateiverwaltungsprobleme
    • Linux-Arbeitsdaten werden innerhalb des ext4.vhdx-Images gespeichert, was Portabilitäts- und Wiederherstellungsrisiken birgt
    • Mit wsl --unregister Distro werden alle Daten sofort gelöscht
    • Bei Nutzung von Windows-Laufwerken (/mnt/c) kommt es durch NTFS + VM-Overhead zu Leistungseinbußen
  • Dateisystemprotokoll
    • WSL1 nutzt drvfs, WSL2 verwendet das 9p-Protokoll von Plan9
    • Ein Bug-Fall wird erwähnt, bei dem im Konvertierungsprozess drvfs verbleibt
  • Alternativen
    • Es wird empfohlen, ein separates VHDX-Image zu erzeugen und mittels wsl --mount --vhd einzubinden, um Arbeitsdaten zu trennen
    • Automatische Konfiguration in .wslconfig ist nicht möglich, Skripte sind erforderlich

Fazit

  • Die modulare Architektur von Windows NT und die stabile Kernel-ABI erhalten die Kompatibilität mit alten Treibern
  • WSL1 hat den Vorteil geringer Speichernutzung, WSL2 bietet mit dem echten Linux-Kernel höhere Kompatibilität und Leistung
  • WSL2 minimiert die Nachteile von VMs und verstärkt die Integration mit dem Host-Betriebssystem
  • Nach klassischer Definition ist es zwar einer VM näher, hat aber als „leichtgewichtig integrierte Umgebung“ genug Grund, als Subsystem bezeichnet zu werden

Verwandte Beiträge

3 Kommentare

 
crawler 2025-12-02

Wow, da ist ja auch Entwickler Sseuk.
 
GN⁺ 2025-12-02
Hacker-News-Kommentar

  • WSL2 läuft auf einer Teilmenge von Hyper-V und ist im Grunde eine VM auf dem Hypervisor.
    Es gibt jedoch Unterschiede zu einer normalen Hyper-V-VM. Zum Beispiel können Linux-Distributionen unter WSL2 dank GPU-Partitionierung, also PCI/GPU-Passthrough, und einer speziellen Implementierung von DirectX auch in X- oder Wayland-Umgebungen GPU-Beschleunigung nutzen.
    Solche Funktionen sind mit Hacks über PowerShell auch in normalem Hyper-V möglich, werden offiziell aber nur unter Windows Server unterstützt.

    • Ich dachte, GPU-Passthrough würde auch unter normalem Windows 11 funktionieren, habe es mir aber nicht genauer angesehen. Trotzdem ist es eine ziemlich beeindruckende Funktion.
    • Im Endeffekt ist es einfach eine normale VM, aber die Automatisierung ist gut.
      Dass „X oder Wayland das Rendering übernimmt“, ist allerdings ein Missverständnis. Tatsächlich nutzt die Anwendung selbst die GPU, und X/Wayland übernimmt nach dem Rendering nur noch die Fensterkomposition.
      Es gibt auch komplexere Aufgaben wie Farbkonvertierung, aber der Rechenaufwand ist gering.
    • Laufen WSL2 und der WinNT-Kernel nicht beide auf Hyper-V im Grunde auf fast derselben Ebene? Natürlich hat der NT-Kernel mehr Rechte für den Hardwarezugriff.
    • Es ist schon komisch, sich vorzustellen, man müsste eine Windows-Server-Lizenz kaufen und installieren, nur um Linux auszuführen.
    • Die Grafik-Integration von WSL2 war für mich enttäuschender als erwartet. Die frühere X-Server-Konfiguration war besser. Allerdings unterstützt X keine modernen APIs, weshalb Entwickler zunehmend das Interesse verlieren. Hoffentlich verbessert sich das mit der wachsenden Unterstützung für WSL2.

  • WSL1 basiert auf Pico Processes und ist eine aus der Drawbridge-Forschung abgeleitete Technologie.
    Siehe dazu das Video The Linux Kernel Hidden Inside Windows 10 und WSL Pico Process Overview.
    Dieselbe Drawbridge-Technologie wird auch verwendet, um SQL Server unter Linux auszuführen.
    Im Ars-Technica-Artikel wird das ausführlich erklärt.

  • Ich verstehe, warum man auf WSL2 umgestiegen ist, aber es ist schade, dass die Entwicklung von WSL1 komplett eingestellt wurde.
    Unsere CI-Umgebung ist größtenteils Linux-basiert, aber einige Toolchains laufen unter Wine nicht gut, etwa MSVC.
    Deshalb brauchten wir eine Umgebung, in der Linux-Builds unter Windows reibungslos laufen. Mit WSL1 war das möglich, aber WSL2 teilt weder Prozess-Namespaces noch File Descriptors, sodass mehrere Workarounds nötig sind.
    Die IO-Geschwindigkeit ist zwar gestiegen, aber das File-Sharing ist langsam und für den praktischen Einsatz ungeeignet.

    • Auch unter WSL2 ist der Zugriff auf Windows-Dateien über /mnt/c möglich.
    • Eine andere Möglichkeit ist die Kombination aus clang-cl und xwin statt MSVC.
      Ich habe auf diese Weise früher einmal Python-C-Erweiterungsmodule gebaut.

  • WSL2 ist eine sehr eng integrierte VM mit der Windows-Umgebung.
    Ich muss wegen der Firmenrichtlinien Windows verwenden und nutze es deshalb täglich für die Entwicklung; in den meisten Fällen ist es ziemlich angenehm.

    • Ich arbeite derzeit in einer von der Firma bereitgestellten VM, aber die Performance wird zunehmend zäh. Ich überlege, auf WSL2 umzusteigen.
      Allerdings basiert unsere Umgebung auf RHEL8, und dass nur Debian-basierte Distributionen unterstützt werden, ist unpraktisch. Mich würde auch interessieren, wie gut die Unterstützung für grafische Apps inzwischen ist.
    • Es heißt zwar „eng integriert“, aber tatsächlich sieht man in ps oder top nur die Prozesse der VM.
      Mit docker run -it ubuntu bekommt man doch etwas Ähnliches; ich frage mich, worin genau der Unterschied liegt.
      Persönlich fand ich den abgetrennten Arbeitsbereich sehr unbequem.

  • WSL2 ist letztlich eine leichtgewichtige VM. Das Konzept ist ähnlich wie bei Firecracker und zielt auf schnelles Booten und geringen Speicherverbrauch ab.
    Wenn man aber mehrere Docker-Container laufen lässt, steigt der Speicherbedarf stark an. Für komfortables Arbeiten sollte man mindestens 20 GB haben.

    • Zum Glück sind Laptops mit 32 GB RAM heute nicht mehr so teuer wie früher.
    • Dass WSL2 in 1–2 Sekunden bootet, ist extrem schnell; ich frage mich, wie das umgesetzt wurde. Dass der BIOS-Bildschirm übersprungen wird, ist klar, aber darüber hinaus scheint es noch weitere Optimierungen zu geben.

  • Persönlich finde ich WSL1 viel nützlicher. Die meisten CLI-Tools wie C++- und .NET-Toolchains oder ssh/scp funktionieren gut.
    Dagegen ist WSL2 für mich fast nutzlos. Wenn ich eine Linux-VM brauche, nutze ich VMware.
    VMware bietet viele Funktionen wie Snapshot-Bäume, 3D-Beschleunigung, USB-Geräteanbindung und virtuelle Netzwerkkonfiguration, außerdem ist die GUI komfortabel.

  • Auf die VM-Festplatte innerhalb von WSL kann über den Pfad \\wsl$ zugegriffen werden.
    Wenn ältere Software keine UNC-Pfade unterstützt, kann man das Problem lösen, indem man einen Laufwerksbuchstaben zuordnet.

  • Es gibt das Problem, dass die VHDX-Datei immer weiter wächst. Man muss sie manuell komprimieren (compact).

    • Es hilft, sparse VHD zu aktivieren. Perfekt ist das nicht, aber mit dem Dienst systemd-trim lässt sich ein Teil des Problems beheben.
      Siehe dazu GitHub WSL #12103.
      Wenn das nicht reicht, kann man auch die manuelle Optimierungsmethode verwenden.
    • Es gibt zwar eine automatische Verkleinerungsfunktion, aber die kann mitunter selbst Probleme verursachen.

  • Zur Info: WSL umgeht standardmäßig die Regeln der Windows-Firewall. Ich frage mich, warum Microsoft das so entworfen hat.

    • Ist das wirklich so? Ich hatte unter WSL immer Probleme mit SSH-Verbindungen.

  • Ich frage mich, ob man eine echte ext4-Partition mounten könnte, um den Performanceverlust durch die Simulation eines blockbasierten Geräts auf Basis einer Image-Datei zu verringern.
 
tangokorea 2026-04-23

Je häufiger ich WSL2 nutze und je weniger ich Linux allmählich direkt verwende, desto mehr frage ich mich: Ist das auch EEE?
EEE – Umarmen, Erweitern und Auslöschen (Embrace, Extend, and Extinguish)