WSL2 on kenji.blog

Hyper-V vs WSL2: Vergleich von Virtualisierungstechnologien auf Windows

Sun, 13 Sep 2026 07:00:00 +0900

1. Einführung: Die Evolution der Virtualisierung unter Windows

Die Virtualisierungstechnologie auf der Windows-Plattform hat sich in den letzten Jahrzehnten dramatisch entwickelt. Früher waren Type-2-Hypervisoren von Drittanbietern (wie VMware Workstation und VirtualBox) der Mainstream, aber seit Microsoft “Hyper-V” in Windows Server 2008 eingeführt hat, sind Type-1-Hypervisoren auch in Desktop-Betriebssysteme wie Windows 10/11 integriert.

In den letzten Jahren hat “WSL2 (Windows Subsystem for Linux 2)” bei Entwicklern die meiste Aufmerksamkeit erregt. Während WSL1 auf die Übersetzung von Systemaufrufen (Translation) angewiesen war, nutzt WSL2 eine “Lightweight Utility VM”, die Hyper-V-Technologie anwendet, um vollständige Linux-Kompatibilität und dramatische Leistungsverbesserungen zu erzielen.

In diesem Artikel werden wir die Architektur, Leistung (CPU, Speicher, Festplatten-I/O), Netzwerkkonfiguration und optimale Anwendungsfälle dieser beiden leistungsstarken Virtualisierungstechnologien – der voll ausgestatteten “Hyper-V” und der auf Entwicklererfahrung fokussierten “WSL2” – mit tiefgreifenden technischen Details ausführlich vergleichen und erklären.

2. Grundlegende Theorie von Hypervisoren und Architekturvergleich

Um die Virtualisierungstechnologie zu verstehen, ist die Typklassifizierung von Hypervisoren (Virtual Machine Monitors: VMM) unerlässlich.

2.1. Unterschiede zwischen Type-1- und Type-2-Hypervisoren

Ein Hypervisor ist eine Softwareschicht, die den Hardwarezugriff abstrahiert und es mehreren Betriebssystemen (Gastbetriebssystemen) ermöglicht, gleichzeitig auf einer einzigen physischen Maschine zu laufen.

Type 1 (Bare-Metal): Läuft direkt auf der Hardware. Das Konzept eines Host-Betriebssystems existiert nicht (streng genommen kann es ein Management-Betriebssystem mit Privilegien geben), was einen extrem geringen Overhead aufweist und hohe Leistung sowie Sicherheit bietet. Beispiele: Hyper-V, VMware ESXi, Xen.
Type 2 (Hosted): Läuft als Anwendung auf einem Host-Betriebssystem (wie Windows oder macOS). Alle Hardwarezugriffe laufen über das Host-Betriebssystem, was zu einem größeren Overhead führt. Beispiele: VMware Workstation, Oracle VirtualBox.

Windows Hyper-V ist ein reiner Type-1-Hypervisor. Wenn Hyper-V aktiviert ist, läuft das Windows-Betriebssystem, mit dem der Benutzer normalerweise interagiert, tatsächlich innerhalb einer speziellen virtuellen Maschine, die als “Root-Partition (Root Partition)” bezeichnet wird.

2.2. Architekturdetails von Hyper-V

Die Hyper-V-Architektur verwendet ein Microkernel-Design und basiert auf logischen Isolationseinheiten, die als Partitionen (Partitions) bezeichnet werden.

graph TD
A["Hardware (CPU, RAM, Festplatte, NIC)"] --> B["Windows Hypervisor (Ring -1)"]
B --> C["Root-Partition (Windows OS)"]
B --> D["Kind-Partition 1 (Windows VM)"]
B --> E["Kind-Partition 2 (Linux VM)"]
C --> F["VMBus (Virtual Machine Bus)"]
D --> F
E --> F
C --> G["VID (Virtualization Infrastructure Driver)"]
C --> H["VMWP.exe (Worker-Prozess)"]

Windows Hypervisor: Läuft im am höchsten privilegierten CPU-Status (Ring -1 oder VMX Root Mode) und ist nur für die Speicherzuweisung und CPU-Planung zuständig. Er enthält keine Gerätetreiber.
Root-Partition: Die Partition, in der das Host-Windows-Betriebssystem läuft. Sie verfügt über alle Gerätetreiber und steuert die Hardware direkt. Sie bietet auch Verwaltungsfunktionen für die Kind-Partitionen (wie WMI-Provider und VMWP.exe).
Kind-Partition (Child Partition): Die Partition, in der das Gastbetriebssystem läuft. Ein direkter Zugriff auf die Hardware ist nicht gestattet; stattdessen sendet sie über einen logischen Memory-Sharing-Bus namens “VMBus” I/O-Anfragen (Synthetic I/O) an die Root-Partition.

2.3. Wie WSL2 und die Lightweight Utility VM funktionieren

WSL2 nutzt die gleiche zugrundeliegende Type-1-Hypervisor-Technologie wie Hyper-V, verwendet jedoch eine Unterfunktion namens “Virtual Machine Platform (VMP)”, die sich von einer voll funktionsfähigen Hyper-V-Maschine unterscheidet.

Die in WSL2 verwendete “Lightweight Utility VM” eliminiert vollständig die Legacy-Hardware-Emulation (wie virtuelles BIOS oder virtuelles Motherboard), über die herkömmliche VMs verfügen.

graph TD
A["Windows Host OS (User Space)"]
B["NTFS-Dateisystem"]
C["9P-Protokoll-Server (Plan 9)"]
D["Lightweight Utility VM (Linux Kernel)"]
E["ext4.vhdx (Virtuelle Festplatte)"]
F["Linux User Space (WSL2-Distributionen)"]
A --> C
C -->| Betriebssystemübergreifende Dateifreigabe | D
D --> E
D --> F

Die größten Merkmale von WSL2 sind seine Startgeschwindigkeit und nahtlose Integration mit dem Host-Betriebssystem. Der Linux-Kernel bootet in weniger als ein paar Sekunden und greift über das 9P-Netzwerkdateisystemprotokoll von Plan 9 auf das Dateisystem der Windows-Seite (NTFS) zu.

3. Gründliche Leistungsanalyse: Rechenressourcen und I/O

Die Leistung einer virtuellen Maschine drückt sich als die Summe des Overheads in CPU-, Speicher- und Festplatten-I/O-Komponenten aus.

3.1. CPU- und Kontextwechsel-Overhead

Sowohl Hyper-V als auch WSL2 verwenden hardwareunterstützte Virtualisierung (Intel VT-x / AMD-V). CPU-Befehle werden grundsätzlich mit nativer Geschwindigkeit ausgeführt, aber bei der Ausführung privilegierter Befehle oder der Verarbeitung von I/O tritt ein Interrupt namens “VM Exit” auf, und es erfolgt ein Kontextwechsel zum Hypervisor.

Der CPU-Overhead $T_{overhead}$ zu dieser Zeit kann durch das folgende mathematische Modell ausgedrückt werden:

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

Wobei:

$N$: Anzahl der VM Exits pro Zeiteinheit
$t_{vm\_exit}$: Übergangszeit vom Gast zum Hypervisor
$t_{hypercall\_process}$: Verarbeitungszeit für I/O oder Interrupts über den VMBus
$t_{vm\_entry}$: Rückkehrzeit vom Hypervisor zum Gast

Da WSL2 keine Legacy-Emulation aufweist, ist $t_{hypercall\_process}$ extrem gering und optimiert. Daher bleibt bei reinen CPU-Berechnungen (wie z.B. Kernel-Kompilierung oder Inferenz von Machine-Learning-Modellen) die Leistungseinbuße im Vergleich zu einer Bare-Metal-Umgebung innerhalb weniger Prozent.

3.2. Mechanismen der Speicherzuweisung

Es gibt einen klaren Unterschied in der Designphilosophie zwischen den beiden in Bezug auf Speicherverwaltungsmethoden.

Hyper-V (Dynamic Memory): Die Root-Partition weist je nach Speicherbedarf der Gast-VM dynamisch Speicher zu und gibt ihn wieder frei. Allerdings wird Speicher, der als Page-Cache im Gast-Betriebssystem reserviert wurde, tendenziell nur dann freigegeben, wenn das System unter Druck steht.
WSL2 (Dynamische Speicherfreigabe): WSL2 verfügt über einen eigenen Mechanismus zur regelmäßigen Rückgabe (Reclaim) von Speicher (einschließlich Cache), der innerhalb der Linux-VM nicht mehr benötigt wird, an den Windows-Host. In frühen Versionen von WSL2 gab es ein Problem, bei dem der Linux-Page-Cache den Windows-Speicher aufzehrte (Aufblähung des Vmmem-Prozesses), was jedoch mittlerweile durch Kernel-Patches behoben wurde.

3.3. Eigenschaften von Festplatten-I/O (VHDX vs ext4.vhdx)

Festplatten-I/O ist der am häufigsten auftretende Flaschenhals in der Leistung virtueller Maschinen.

Die I/O-Latenz $L_{total}$ wird wie folgt berechnet:

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

Im Falle von Hyper-V: Typische Hyper-V-Gäste verwenden virtuelle Festplatten im VHDX-Format. I/O-Anfragen, die vom Dateisystem (ext4 oder NTFS) innerhalb des Gastbetriebssystems ausgegeben werden, durchlaufen den VMBus-Block-Device-Storage-Treiber (storvsc) und werden als Zugriff auf die VHDX-Datei auf dem NTFS-Dateisystem der Windows-Seite verarbeitet.

Im Falle von WSL2: WSL2-Linux-Distributionen laufen auf einem nativen ext4-Dateisystem, das in einer dedizierten ext4.vhdx-Datei erstellt wurde. Dateioperationen innerhalb von Linux (wie im ~ Verzeichnis) bieten eine native Leistung, die der von Hyper-V oben entspricht. Wenn Sie jedoch von WSL2-Linux auf Dateien auf der Windows-Seite zugreifen (wie /mnt/c/), oder umgekehrt, ist der Prozess ganz anders. Dieses Cross-OS-Zugriffsverfahren nutzt das 9P (Plan 9 File System Protocol).

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

Der Zugriff über dieses 9P-Protokoll weist einen hohen Overhead für Serialisierungsverarbeitung auf, und bei Anwendungen, die eine große Anzahl kleiner Dateien lesen und schreiben (z.B. npm install oder Git-Operationen in einem Node.js-Projekt in einem Windows-Verzeichnis), verschlechtert sich die Leistung erheblich (manchmal mehr als die 10-fache Verzögerung). Aus diesem Grund ist es eine eiserne Regel bei der Verwendung von WSL2, Projektdateien immer im nativen Linux-Dateisystem (unter ~/) abzulegen.

4. Netzwerkstruktur: NAT, Default Switch, Bridged

Die Flexibilität der Netzwerkfunktionen ist einer der Hauptunterschiede zwischen Hyper-V und WSL2.

4.1. Netzwerk von WSL2 (NAT-basiert)

Standardmäßig nutzt das WSL2-Netzwerk eine “NAT (Network Address Translation)"-Konfiguration unter Verwendung der Virtual Switch-Technologie von Hyper-V. Der Linux-VM wird automatisch eine private IP-Adresse zugewiesen (z.B. 172.20.x.x), die sich vom Windows-Host unterscheidet. Ein Mechanismus ist integriert, der Dienste (Ports), die innerhalb von WSL2 gestartet wurden, vom Windows-Host als localhost weiterleitet, sodass Entwickler Webserver usw. testen können, ohne sich der Netzwerkkonfiguration bewusst sein zu müssen.

In den letzten Jahren wurde in einer Vorschauversion ein neuer Netzwerkmodus namens “Mirrored Mode” für WSL2 eingeführt. Dies verbessert die IPv6-Unterstützung und die VPN-Verbindungskompatibilität (kann in .wslconfig konfiguriert werden).

4.2. Hyper-V Virtual Switch

Hyper-V ermöglicht die Erstellung von fortgeschrittenen Netzwerken auf Enterprise-Niveau. Über den “Virtual Switch Manager” bietet es hauptsächlich drei Modi:

Extern (External): Bindet die physische NIC der Hostmaschine an den Virtual Switch, sodass die Gast-VM direkt an das physische Netzwerk angeschlossen wird (Bridged Connection). Die VM bezieht eine IP aus dem gleichen Subnetz wie das physische Netzwerk vom DHCP-Server.
Intern (Internal): Erlaubt nur die Kommunikation zwischen dem Host OS und der VM sowie zwischen VMs. Sie können nicht direkt nach außen kommunizieren.
Privat (Private): Erlaubt nur die Kommunikation zwischen VMs und blockiert auch die Kommunikation mit dem Host OS. Wird verwendet, um isolierte Testumgebungen zu erstellen.

4.3. Fortgeschrittene Hyper-V Netzwerkkonfiguration mit PowerShell

In Entwicklungs- oder Testumgebungen ermöglicht PowerShell eine detaillierte Kontrolle, wenn Sie ein benutzerdefiniertes NAT-Netzwerk für VMs erstellen möchten. Nachfolgend ein Skriptbeispiel, um einen internen Virtual Switch zu erstellen, NAT zu konfigurieren und VMs Internetzugang zu ermöglichen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Erstellung eines internen Virtual Switch
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. IP-Adresse für die virtuelle Host-NIC festlegen (Gateway-IP)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. Konfiguration des NAT-Netzwerks
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# Befehl zur Überprüfung
Get-NetNat

Mit dieser Konfiguration können Sie ein eigenes NAT-Segment aufbauen, das über den Host mit der Außenwelt kommunizieren kann, indem Sie der angegebenen Hyper-V-Gastmaschine manuell eine 192.168.100.x IP und das Gateway 192.168.100.1 zuweisen.

5. Anwendungsfälle und praktischer Leitfaden zur Auswahl

Basierend auf den bisherigen Architektur- und Leistungsunterschieden definieren wir, in welchen Situationen welche Technologie angewendet werden sollte.

5.1. Szenarien, in denen WSL2 gewählt werden sollte

WSL2 ist speziell zur “Steigerung der Produktivität von Entwicklern” konzipiert. Es ist ideal für folgende Zwecke:

Webentwicklung und Cloud-native Entwicklung: Containerentwicklung mit Docker Desktop (WSL2-Backend) oder Podman.
Verwendung von dedizierten Linux-Tools: Bei der täglichen Verwendung von bash, grep, awk, sed oder GCC/Clang-Compilern für Linux.
GUI-Anwendungen (WSLg): Wenn Sie Linux-X11/Wayland-Anwendungen nahtlos auf dem Windows-Desktop ausführen möchten.
Machine Learning und KI-Entwicklung: Schnelles Training mit TensorFlow oder PyTorch unter Verwendung von GPU-Passthrough-Funktionen (NVIDIA CUDA on WSL).

Hinweis: Einschränkungen können auftreten, wenn Sie den Kernel stark anpassen möchten oder komplexe Dienste aufbauen, die stark von systemd abhängen (obwohl systemd derzeit unterstützt wird, ist es standardmäßig deaktiviert oder eingeschränkt).

5.2. Szenarien, in denen Hyper-V gewählt werden sollte

Hyper-V ist auf “Infrastrukturvirtualisierung und vollständige Isolation” ausgerichtet. Es ist unverzichtbar für folgende Zwecke:

Ausführung von Windows VMs: Zum Ausführen verschiedener Windows-Versionen (z.B. Windows Server oder ein älteres Windows 10) als Testumgebungen.
Nested Virtualization (verschachtelte Virtualisierung): Wenn Sie eine virtuelle Maschine (Hyper-V oder KVM) innerhalb einer anderen virtuellen Maschine ausführen möchten. Unerlässlich für die Testumgebungen von Infrastruktur-Ingenieuren.
Fortgeschrittene Netzwerkanforderungen: Wenn Sie die Netzwerkkonfiguration strikt kontrollieren müssen, wie z.B. bei externen Bridged-Verbindungen (Teilnahme am selben LAN), VLAN-Tagging, Zuweisung mehrerer NICs, usw.
Snapshots (Checkpoints): Eine Funktion, mit der Sie den Zustand einer VM zu einem bestimmten Zeitpunkt speichern und jederzeit sofort zurücksetzen können. Äußerst nützlich für destruktive Softwaretests oder Malware-Analysen.
Feste Ressourcenzuweisung: Wenn Sie die Anzahl der CPU-Kerne und die Speichermenge strikt fixieren möchten, um die Auswirkungen auf das Host OS zu minimieren.

6. Überlegungen zum I/O-Durchsatz anhand mathematischer Modelle (Anhang)

Als Systemingenieur ist es wichtig, die Beziehung zwischen Durchsatz $S$ und Blockgröße $B$ theoretisch zu verstehen, wenn man die Grenzen der I/O-Leistung beider Technologien bewertet.

Der Datentransfer-Durchsatz $S$ ist die pro Zeiteinheit übertragene Datenmenge und wird wie folgt modelliert:

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: Blockgröße (Bytes)
$L_{setup}$: Feste Latenz im Zusammenhang mit der Einrichtung von I/O-Anfragen und dem Kontextwechsel
$R_{max}$: Maximale Hardware-Bandbreite bei Kopien oder Geräteübertragungen

Beim Dateizugriff über das 9P-Protokoll von WSL2 wird dieser $L_{setup}$ sehr groß (aufgrund von Socket-Kommunikation und der Serialisierung/Deserialisierung von Protokollen). Wenn die Blockgröße $B$ gering ist (Lesen und Schreiben vieler kleiner Dateien von wenigen KB), wird daher der Einfluss von $L_{setup}$ im Nenner dominant, und der Durchsatz $S$ sinkt drastisch. Im Gegensatz dazu wird beim VHDX-Zugriff über den VMBus von Hyper-V der $L_{setup}$ auf ein Niveau nahe einem Hardware-Interrupt optimiert, sodass hohe IOPS auch bei kleinen Blöcken aufrechterhalten werden können.

Diese mathematische Realität ist die logische Grundlage für die Best Practice: “Projektdateien sollten unter WSL2 nicht auf der Windows-Seite abgelegt werden”.

7. Zusammenfassung: Zwei koexistierende Virtualisierungstechnologien

Hyper-V und WSL2 sind nicht so, dass das eine besser ist als das andere, sondern “zwei Lösungen mit unterschiedlichen Zielen”.

WSL2 ist das “beste Integrationstool”, um die Hülle des Windows-Betriebssystems zu durchbrechen und das Linux-Ökosystem Windows-Benutzern nahtlos und mit hoher Geschwindigkeit zur Verfügung zu stellen. Es ist keine Übertreibung zu sagen, dass dies die ultimative CLI-Umgebung für Entwickler ist.
Hyper-V ist ein “vollwertiger Hypervisor”, der die robuste Isolation und Verwaltungsfunktionen, die in Enterprise-Rechenzentren entwickelt wurden, auf den Desktop bringt. Beim Aufbau von Netzwerken, Testen von Windows-Betriebssystemen und Simulieren von Infrastrukturumgebungen ist er unübertroffen.

In der modernen Windows-Umgebung konkurrieren diese beiden Technologien nicht, sondern koexistieren harmonisch auf derselben VM-Plattform. Durch den richtigen Einsatz beider Technologien je nach Verwendungszweck wird Windows zur leistungsstärksten und flexibelsten Engineering-Workstation der Welt.

Der ultimative Leitfaden zur Einrichtung der Entwicklungsumgebung in WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

„WSL2 (Windows Subsystem for Linux 2)“, das eine native Linux-Entwicklungsumgebung unter Windows bietet, ist zu einem unverzichtbaren Werkzeug in der modernen Softwareentwicklung geworden. Es gibt jedoch einen himmelweiten Unterschied in Leistung und Entwicklungserfahrung zwischen der weiteren Nutzung im Standardzustand und dem Verständnis der Architektur zur entsprechenden Optimierung.

Dieser Artikel beginnt mit einer Erklärung der Architektur, die das Fundament von WSL2 bildet. Er behandelt ausführlich alle Schritte zum Aufbau der „ultimativen Entwicklungsumgebung“, die professionelle Ingenieure verlangen, einschließlich Konfigurationen zur Maximierung der Leistung, Aufbau einer komfortablen Terminalumgebung, nahtlose Integration mit Docker und VS Code sowie erweiterte Netzwerkeinstellungen, mit einem Umfang von über 10.000 Zeichen.

1. WSL2-Architektur und die Evolution von WSL1

Um das Potenzial von WSL2 voll auszuschöpfen, ist es wichtig, zuerst seine interne Struktur zu verstehen. Das erste WSL (WSL1) und WSL2 unterscheiden sich grundlegend in ihrem Ansatz, Linux-Binärdateien unter Windows auszuführen.

WSL1: Systemcall-Übersetzungsebene

WSL1 verwendete einen Mechanismus zur Übersetzung von Linux-Systemaufrufen in Windows-NT-APIs in Echtzeit. Dies hatte den Vorteil eines sehr geringen Ressourcen-Overheads, da keine virtuelle Maschine (VM) verwendet wurde. Es war jedoch schwierig, komplexe Systemaufrufe wie Dateisystem-I/O-Operationen vollständig zu emulieren. Dies führte zu einer katastrophalen Leistungseinbuße, insbesondere bei der Verarbeitung einer großen Anzahl kleiner Dateien, wie z.B. npm install von Node.js oder Git-Repository-Operationen.

WSL2: Lightweight Utility VM und vollständiger Linux-Kernel

Bei WSL2 wurde die Architektur erneuert, und ein von Microsoft erstellter echter Linux-Kernel läuft jetzt direkt auf einer „Lightweight Utility VM“, die eine Teilmenge der Hyper-V-Architektur nutzt. Dies garantiert 100%ige Kompatibilität von Systemaufrufen, und durch die Verwendung einer virtuellen Festplatte (VHDX) mit dem nativen Linux-Dateisystem ext4 hat sich die Datei-I/O-Leistung im Vergleich zu WSL1 dramatisch verbessert.

Das folgende Mermaid-Diagramm zeigt die strukturellen Unterschiede zwischen WSL1 und WSL2.

flowchart TD
subgraph "Windows OS-Umgebung"
A["Windows NT-Kernel"]
A --> F["NTFS-Dateisystem (C:-Laufwerk)"]
end
subgraph "WSL2-Architektur"
B["Hyper-V-Hypervisor"]
B --> C["Lightweight Utility VM"]
C --> D["Linux-Kernel (Microsoft)"]
D --> E["Ubuntu User Space (glibc, bash usw.)"]
D --> G["Virtuelle ext4-Festplatte (.vhdx)"]
end
A -.->|"Plan 9 (9P) Protocol Network File Share"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

Die wichtigste Lektion aus dieser Struktur ist: „Der Zugriff auf Dateien auf der Linux-Seite (innerhalb von VHDX) ist extrem schnell, aber der Zugriff auf Dateien auf der Windows-Seite (/mnt/c/) ist sehr langsam, da er über das 9P-Protokoll erfolgt.“ Der Quellcode für Ihre Projekte muss unter dem Home-Verzeichnis (~) auf der WSL-Seite abgelegt werden.

2. Mathematische Leistungsanalyse: Warum ist WSL2 schnell?

Lassen Sie uns die Leistungssteigerung von WSL2 mithilfe eines mathematischen Modells quantitativ bewerten. Eine der zeitaufwändigsten Operationen in der Softwareentwicklung ist die Verarbeitung, die mit einer großen Menge an Datei-I/O einhergeht (z.B. Bibliotheksinstallation und Build).

Die Gesamtausführungszeit $T_{total}$ eines bestimmten Prozesses wird durch die Summe der CPU-Berechnungszeit $T_{compute}$ und der Festplatten-I/O-Zeit $T_{io}$ ausgedrückt.

$$ T_{total} = T_{compute} + T_{io} $$

Im Fall von WSL1, da ein Overhead für die Konvertierung von Operationen auf der Linux-Seite in NTFS-Operationen entsteht, wird die I/O-Zeit wie folgt modelliert. Hierbei ist $n$ die Anzahl der Dateioperationen, $t_{ntfs\_syscall}$ die Ausführungszeit des Systemaufrufs auf der Windows-Seite und $t_{trans}$ der Overhead der Übersetzungsebene.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

Im Fall von WSL2, da der Kernel direkt I/O an das ext4-Dateisystem ausgibt, besteht der Overhead nur aus der sehr geringen Verzögerung $t_{virt}$ durch die Virtualisierung.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

In allgemeinen Dateisystemen ist $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$. Wenn also $n$ sehr groß ist (Zehntausende bis Hunderttausende von Dateioperationen durchführen), vergrößert sich der Unterschied in der I/O-Zeit zwischen WSL1 und WSL2 exponentiell.

Wenn wir außerdem das Overhead-Verhältnis der CPU-Berechnung in einer virtualisierten Umgebung mit $\rho$ ansetzen, bleibt es bei der neuesten hardwareunterstützten Virtualisierung (Intel VT-x / AMD-V) bei etwa $\rho \approx 0.01 \sim 0.03$ (1-3%). Daher wird selbst bei reinen Rechenaufgaben eine Leistung von $97\% \sim 99\%$ erreicht, was der einer nativen Linux-Umgebung in nichts nachsteht.

3. Installation und Aufbau der Grundlagen

Unter Windows 10/11 ist die Installation von WSL2 sehr einfach geworden. Öffnen Sie einfach PowerShell mit Administratorrechten und führen Sie den folgenden Befehl aus.

1
2
3
4
5
6


# WSL2 und Ubuntu werden standardmäßig installiert
wsl --install

# Wenn Sie eine bestimmte Distribution angeben
# Kann mit wsl --list --online überprüft werden
wsl --install -d Ubuntu-24.04

Nach der Installation und einem Neustart werden Sie beim ersten Start aufgefordert, einen UNIX-Benutzernamen und ein Passwort festzulegen. Dieser Benutzer ist unabhängig von Ihrem Windows-Benutzer und nur innerhalb von WSL gültig.

Wenn Sie bereits WSL1 verwenden, können Sie es mit den folgenden Befehlen in WSL2 konvertieren.

1
2
3
4
5


# Konvertieren Sie die vorhandene Distribution in WSL2
wsl --set-version Ubuntu 2

# Machen Sie WSL2 zur Standardversion für zukünftige Distributionen
wsl --set-default-version 2

4. Das Geheimnis der Ressourcenkontrolle: .wslconfig und wsl.conf

Eine der größten Fallen von WSL2 ist der „unbegrenzte Speicherverbrauch (Aufblähen des Vmmem-Prozesses)“. Da WSL2 den Page Cache des Linux-Kernels verwendet, verbraucht es bei jedem I/O unendlich viel Host-Speicher (Windows). Um dies zu verhindern, ist es zwingend erforderlich, Ressourcen über Konfigurationsdateien zu begrenzen.

Es gibt zwei WSL2-Konfigurationsdateien: .wslconfig, die das gesamte Windows betrifft, und wsl.conf, die das Innere jeder Distribution betrifft.

4.1. .wslconfig (Windows-Seite)

Erstellen Sie eine Datei im Windows-Benutzerprofilverzeichnis (C:\Users\<Benutzername>\.wslconfig), um die Ressourcenzuweisung an die VM zu steuern.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<Benutzername>\.wslconfig
[wsl2]
# Maximale Speichermenge, die der VM zugewiesen werden soll. Es werden etwa 50% bis 75% des gesamten Host-Speichers empfohlen
memory=16GB

# Anzahl der zu verwendenden CPU-Kerne (alle Kerne werden verwendet, wenn weggelassen)
processors=8

# Größe der Auslagerungsdatei
swap=8GB

# Speicherort der Auslagerungsdatei (wenn Sie Speicherplatz auf dem Laufwerk C sparen möchten)
# swapfile=D:\\wsl\\swap.vhdx

# Aktivieren Sie das Localhost-Forwarding (um auf WSL von der Windows-Seite über localhost zuzugreifen)
localhostForwarding=true

# Speicher automatisch freigeben (nur Windows 11)
# Gibt den Page Cache dynamisch frei und verhindert ein Aufblähen von Vmmem
autoMemoryReclaim=dropcache

[experimental]
# Erweiterte Netzwerkfunktionen für Windows 11 22H2 und neuer
# Dies ermöglicht IPv6-Unterstützung und die gemeinsame Nutzung derselben IP-Adresse zwischen WSL und Windows
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Linux-Seite)

Bearbeiten Sie /etc/wsl.conf in WSL, um das distributionsspezifische Verhalten zu steuern.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (In WSL bearbeitet)
[network]
# Deaktivieren Sie die Generierung von /etc/resolv.conf, das beim Start von WSL automatisch generiert wird
# Nützlich, wenn Sie ein eigenes DNS einrichten möchten (z. B. 8.8.8.8)
generateResolvConf=false

# Festlegen eines eigenen Hostnamens
hostname=WSL-DevNode

[automount]
# Einstellungen beim Mounten von Windows-Laufwerken
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Ändern Sie den Mount-Punkt des Laufwerks C von /mnt/c auf /c (verkürzt den Pfad)
root=/

[boot]
# systemd aktivieren (WSL 0.67.6 und neuer)
# Dadurch können snap und verschiedene Daemons (wie Docker) nativ ausgeführt werden
systemd=true

[user]
# Standardmäßig angemeldeter Benutzer
default=kenji

Um diese Einstellungen anzuwenden, müssen Sie wsl --shutdown in PowerShell ausführen, um die WSL-VM vollständig zu stoppen, und sie dann neu starten.

5. Die ultimative Terminal-Umgebung: Zsh + Powerlevel10k

Mit der Standard-Bash allein steigt Ihre Produktivität nicht. Durch die Kombination von Zsh, das sich durch leistungsstarke Vervollständigung und Sichtbarkeit auszeichnet, mit dem ultraschnellen Thema „Powerlevel10k“, bauen wir die stärkste Eingabeaufforderung.

5.1. Installation und Konfiguration von Windows Terminal

Installieren Sie „Windows Terminal“ aus dem Microsoft Store. Öffnen Sie die JSON-Einstellungen (settings.json), legen Sie das Standardprofil auf WSL (Ubuntu) fest und ändern Sie die Schriftart in einen Nerd Font für die Entwicklung (z.B. HackGen Console NF oder MesloLGS NF).

5.2. Zsh und Oh My Zsh installieren

Führen Sie die folgenden Befehle im WSL-Terminal aus.

1
2
3
4
5
6


# Pakete aktualisieren und Zsh installieren
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Führen Sie das Installationsskript für Oh My Zsh aus
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Einführung von Powerlevel10k und Plugins

Wir werden Plugins (Syntax-Hervorhebung und Eingabevervollständigung) und das Powerlevel10k-Thema einführen, um Zsh weiter zu verbessern.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Bearbeiten Sie ~/.zshrc, um das Thema und die Plugins zu aktivieren.

1
2
3
4
5


# Änderungen an ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Zum Plugin-Array hinzufügen
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Wenn Sie es speichern und source ~/.zshrc ausführen, wird der Powerlevel10k-Konfigurationsassistent (p10k configure) gestartet. Folgen Sie den Anweisungen auf dem Bildschirm, um Ihre bevorzugte Eingabeaufforderung (Eingabeaufforderungsstil, ob Symbole vorhanden sind, anzuzeigende Informationen usw.) anzupassen. Der Git-Zweigname und -Status, die Node.js-Version, die Ausführungszeit von Befehlen usw. werden in Echtzeit angezeigt, wodurch die Entwicklungseffizienz drastisch verbessert wird.

6. VS Code Remote - Nahtlose Integration mit WSL

Für die Entwicklung auf WSL2 gibt es eine „Remote - WSL“-Erweiterung, die Ihnen den nahtlosen Zugriff auf Dateien innerhalb von WSL von der auf der Windows-Seite installierten IDE (Visual Studio Code) ermöglicht.

Erklärung der Architektur

Das folgende Sequenzdiagramm zeigt, wie VS Code mit WSL2 kommuniziert.

sequenceDiagram
autonumber
participant U as "Entwickler"
participant V as "VS Code UI (Windows)"
participant S as "VS Code Server (WSL2)"
participant F as "ext4-Dateisystem (WSL2)"
U->>V: "Geben Sie `code .` in WSL Terminal ein"
V->>S: "Aufbau einer RPC-Verbindung über Vsock"
Note over V,S: Kommunikation über Hyper-V-Sockets ohne TCP/IP
S->>F: "Quelldateien lesen / Linter ausführen"
F-->>S: "Daten & Analyse zurückgeben"
S-->>V: "Language Server-Ergebnisse an UI streamen"
V-->>U: "Syntax-Highlighting & Fehler anzeigen"

Der VS Code auf der Windows-Seite fungiert als reiner „Thin Client (UI)“, und rechenintensive Aufgaben wie der Language Server, der Debugger und die Terminal-Ausführung werden alle vom „VS Code Server“ auf der WSL-Seite erledigt. Auf diese Weise können Sie die Umgebung auf der WSL-Seite sauber halten, ohne Node.js oder Python auf der Windows-Seite zu installieren.

Wesentliche VS Code-Einstellungen

Installieren Sie “WSL” (ms-vscode-remote.remote-wsl) aus den “Erweiterungen” von VS Code. Navigieren Sie dann im WSL-Terminal zum Projektverzeichnis und führen Sie einfach code . aus, um den VS Code auf der Windows-Seite mit dem geöffneten Verzeichnis zu starten.

Wichtiger Hinweis (Problem mit dem Zeilenumbruchcode): Windows und Linux haben unterschiedliche Zeilenumbruchcodes (Windows verwendet CRLF, Linux verwendet LF). Bei der Entwicklung in WSL stellen Sie bitte sicher, dass die Git-Einstellung core.autocrlf und die Standarddateieinstellungen von VS Code auf LF vereinheitlicht werden. Wenn Sie dies versäumen, werden Sie von mysteriösen Fehlern bei der Ausführung von Shell-Skripten oder Docker-Containern geplagt.

1
2


# Git-Zeilenumbruchcode-Einstellung auf der WSL-Seite
git config --global core.autocrlf input

Fügen Sie der settings.json (Remote-Einstellung) von VS Code auch Folgendes hinzu:

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Optimierung von Docker Desktop und WSL2 Integration

Es gibt hauptsächlich zwei Ansätze zur Verwendung von Docker in einer WSL2-Umgebung.

Installieren Sie Docker Desktop für Windows und aktivieren Sie die WSL2-Integrationsfunktion
Installieren Sie die native Docker Engine direkt innerhalb von WSL2 (z. B. Ubuntu)

Ansatz 1: Docker Desktop (Empfohlen)

Dies wird in den meisten Fällen empfohlen, da es ein einfaches Management mit einer GUI und einen transparenten Zugriff auf Container zwischen Windows und WSL ermöglicht. Überprüfen Sie Folgendes in den Einstellungen von Docker Desktop (Settings).

Aktivieren Sie General -> Use the WSL 2 based engine.
Aktivieren Sie Resources -> WSL Integration -> Enable integration with my default WSL distro und aktivieren Sie die zu verwendende Distribution (Ubuntu) mit der Umschaltfläche.

Dies ermöglicht es Ihnen, den docker-Befehl direkt aus dem WSL2-Terminal auszuführen, und die Kommunikation mit dem Docker-Daemon erfolgt über dedizierte Lightweight-VMs (docker-desktop und docker-desktop-data), die von Docker Desktop verwaltet werden.

Ansatz 2: Direkte Installation der nativen Docker Engine

Wenn Sie Unternehmensnetzwerkeinschränkungen haben (z. B. um die Kosten für Docker Desktop zu vermeiden) oder den Leistungs-Overhead so weit wie möglich reduzieren möchten, aktivieren Sie systemd in /etc/wsl.conf und installieren Sie Docker als reinen Ubuntu-Server.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Auszug aus dem offiziellen Docker-Installationsverfahren auf WSL2 Ubuntu mit aktiviertem systemd
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Repository hinzufügen
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Fügen Sie den aktuellen Benutzer zur docker-Gruppe hinzu (um ohne sudo auszuführen)
sudo usermod -aG docker $USER

Nach dem Neustart funktioniert systemctl start docker genau wie in einer nativen Linux-Umgebung und bietet hohe Leistung.

8. Integration von SSH-Schlüsseln: Nahtlose Authentifizierung in Windows und WSL

Bei der Durchführung von SSH-Klonen in Git oder Verbindungen zu Remote-Servern über SSH ist es sehr mühsam, separate SSH-Schlüssel auf der Windows- und der WSL-Seite zu verwalten. Um Sicherheit und Komfort in Einklang zu bringen, richten wir eine Brücke vom auf der Windows-Seite laufenden SSH-Agenten (oder einem Passwort-Manager wie 1Password) zur WSL-Seite ein.

Hier erklären wir die sicherste und modernste Methode, den SSH-Agenten von 1Password oder den OpenSSH Authentication Agent von Windows zu verwenden und ihn mithilfe von npiperelay oder socat an den UNIX-Domain-Socket von WSL2 weiterzuleiten.

ssh-agent Socket-Weiterleitung

Normalerweise muss der als Named Pipe (benannte Pipe) in Windows bereitgestellte SSH-Agent in eine Socket-Datei auf der WSL-Seite konvertiert werden. Dies lässt sich mithilfe von wsl-ssh-agent oder Funktionen von 1Password leicht erreichen.

Aktivieren Sie im Einstellungsbildschirm von 1Password “Entwickler” -> “SSH-Agenten verwenden”. Fügen Sie als Nächstes die folgenden Einstellungen zur ~/.zshrc oder ~/.bashrc auf der WSL-Seite hinzu, um den Socket bei der Anmeldung automatisch zu binden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Zu ~/.zshrc hinzufügen (Beispiel für die Verwendung des 1Password SSH Agent)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Wenn der Socket beim Start von WSL nicht existiert oder der Prozess nicht gebunden ist, mit socat und npiperelay weiterleiten
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Starten Sie socat im Hintergrund und verbinden Sie die Named Pipe auf der Windows-Seite mit dem UNIX-Socket auf der WSL-Seite
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

*Vorab müssen Sie npiperelay.exe auf der Windows-Seite installieren und den Pfad konfigurieren.

Nach Abschluss dieser Konfiguration wird bei Ausführung von ssh-add -l aus dem WSL-Terminal eine Liste der öffentlichen Schlüssel von SSH-Schlüsseln angezeigt, die in 1Password oder auf der Windows-Seite registriert sind. Auf diese Weise können Sie sich sicher authentifizieren, ohne die private Schlüsseldatei nach WSL kopieren zu müssen.

9. Wartung: Optimierung (Komprimierung) von aufgeblähten VHDX

Einer der größten Nachteile von WSL2 ist die Tatsache, dass die Dateigröße der virtuellen Festplatte (.vhdx) auf der Windows-Seite nicht automatisch reduziert wird, selbst wenn Sie Docker-Images oder Dateien löschen. Wenn Sie lange Zeit weiterentwickeln, bläht sich die Datei ext4.vhdx auf Dutzende bis Hunderte von GB auf.

Um Speicherplatz freizugeben, müssen Sie VHDX regelmäßig von der Windows-Seite aus optimieren (komprimieren).

Schalten Sie zunächst WSL vollständig aus.
1

wsl --shutdown
Öffnen Sie PowerShell mit Administratorrechten und führen Sie den folgenden Befehl diskpart oder den Befehl Optimize-VHD des Hyper-V-Moduls aus (letzteres kann nur verwendet werden, wenn Hyper-V aktiviert ist).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Wenn das Hyper-V-Modul verfügbar ist
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# Wenn Sie diskpart verwenden
diskpart
# Geben Sie interaktiv innerhalb des folgenden Prompts ein
DISKPART> select vdisk file="C:\Users\<Benutzername>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

Wenn Sie diesen Vorgang regelmäßig durchführen, können Sie die auf Laufwerk C verschwendete Kapazität zurückgewinnen.

10. Fazit

WSL2 hat den Rahmen eines bloßen „Zusatz-Linux, das unter Windows läuft“ komplett überschritten und sich zu einer leistungsstarken Entwicklungsplattform entwickelt, die einer MacOS- oder nativen Linux-Maschine in nichts nachsteht oder diese sogar übertrifft.

Durch die Anwendung aller hier erläuterten Einstellungen (Ressourcenoptimierung durch .wslconfig, Terminalerweiterung durch Zsh + Powerlevel10k, transparenter Zugriff durch VS Code Remote sowie SSH-Integration und VHDX-Wartung) wird eine stressfreie, schnelle und sichere „ultimative Entwicklungsumgebung“ vervollständigt.

Der Aufbau der Umgebung erfordert zwar etwas Aufwand, aber wenn Sie die Einstellungen einmal festgelegt haben, wird sich Ihre zukünftige Engineering-Produktivität zweifellos dramatisch verbessern. Erkunden Sie gerne weitere Anpassungen basierend auf diesem Leitfaden, um sie an Ihre eigenen Projekte und Vorlieben anzupassen.