WSL Container sind da – Windows-Apps starten Linux-Container

Microsoft hat die WSL Container (WSLC) allgemein verfügbar gemacht. Damit bekommt das Windows Subsystem for Linux eine eigene Container-Plattform. Das Kommandozeilenwerkzeug wslc.exe baut und startet Linux-Container direkt unter Windows, über eine API können Windows-Anwendungen dasselbe tun. wslc.exe ist Bestandteil von WSL, eine separate Container-Engine muss man nicht installieren. Neu zur allgemeinen Verfügbarkeit sind zusätzliche Befehle und Verwaltungsfunktionen für Unternehmen.

Vorgestellt hatte Microsoft die WSL Container Anfang Juni auf der Build 2026. Die erste öffentliche Vorschau erschien am 29. Juni mit WSL 2.9.3.

Docker-ähnliche Befehle, API für Windows-Apps

Wie Microsoft im Windows Developer Blog zur allgemeinen Verfügbarkeit schreibt, genügt zur Installation ein wsl --update. Alternativ steht das aktuelle Release auf GitHub bereit: Konkret handelt es sich um WSL 3.0.1, veröffentlicht am 29. September. Auf Wunsch lässt sich die CLI auch unter dem Alias container.exe aufrufen. Wer Docker kennt, findet sich schnell zurecht: Befehle wie wslc run, wslc build oder wslc container list orientieren sich an der Docker-Syntax. Einen nginx-Webserver im Hintergrund startet etwa wslc run -d --rm -p 8080:80 --name web nginx.

Die zweite Komponente richtet sich an Entwickler von Windows-Anwendungen. Die API steht als NuGet-Paket `Microsoft.WSL.Containers` für C, C# und C++ bereit. Damit starten und stoppen Programme Container und kommunizieren direkt mit ihnen. Eine Windows-Anwendung kann so zum Beispiel einen Linux-Dienst im Container hochfahren, statt ihn nach Windows zu portieren. Als Einsatzszenarien nennt Microsoft lokale KI-Workloads und containerisierte Cloud-Anwendungen, die sich lokal ausführen lassen.

Neue Befehle seit der Vorschau

Seit der Vorschau hat Microsoft vor allem den Container-Lebenszyklus, das Netzwerk und die Überwachung ausgebaut. wslc container restart startet laufende Container neu, wslc container cp kopiert Dateien per tar-Archiv hinein und heraus. wslc system info informiert über den Zustand der Container-Umgebung, wslc events streamt Container-Aktivitäten in Echtzeit. Mit wslc network connect beziehungsweise disconnect lassen sich Container an Netzwerke hängen und wieder lösen. wslc network create akzeptiert jetzt beliebige Treiberoptionen.

Außerdem unterstützt WSLC jetzt Health Checks. wslc create und wslc run kennen ab sofort die Optionen --mount und --stop-timeout, mit -1 als Wert für ein unbegrenztes Timeout. Den Speicherpfad der Standard-Session kann man jetzt selbst festlegen, um den Container-Speicher auf ein beliebiges Laufwerk zu legen. Die vollständigen Änderungen listet der Changelog auf der GitHub-Releaseseite von WSL auf.

Eigener Prozess pro Session

Unter der Haube weicht WSLC in einigen Punkten von der klassischen WSL-Architektur ab. Detailliert beschreibt Microsoft das in einem Blogbeitrag zur Architektur der WSL Container. Wie bei WSL rufen Client-Prozesse den privilegierten Windows-Dienst wslservice.exe auf, der über den Host Compute Service (HCS) virtuelle Maschinen erzeugt. Anders als bei WSL behält der Dienst die VM aber nicht selbst. Er startet dafür den Kindprozess wslcsession.exe, der im Namen des aufrufenden Nutzers läuft und alle Session-Operationen erledigt, etwa Container anlegen, Verzeichnisse einhängen oder Ports binden. Sessions sind dadurch voneinander isoliert, und die eigentliche Arbeit läuft mit weniger Rechten als der Dienst.

Jede Session hat eine eigene virtuelle Festplatte (VHD), in der Images, Container, Netzwerke und Volumes liegen. Windows-Verzeichnisse reicht WSLC per virtiofs an die Linux-VM weiter und bindet sie von dort per Bind-Mount in den Container ein. virtiofs ist ein Dateisystem, das speziell für den Datenaustausch zwischen Hypervisor und VM entwickelt wurde. Laut Microsoft ist es etwa doppelt so schnell wie Plan 9, also das 9P-Protokoll, über das WSL 2 bislang auf Windows-Dateien zugreift. Als Alternative gibt es VHD-Volumes, die ein natives Linux-Dateisystem bereitstellen oder die Größe eines Volumes begrenzen.

Fürs Netzwerk führt Microsoft das neue Modell Consommé ein. Die Kompatibilität sei schwierig, weil es sehr viele verschiedene Netzwerkkonfigurationen mit VPNs, Proxys und mehr gibt, räumte Microsoft schon zur Vorschau ein. Bei Consommé verlässt der Datenverkehr die VM im Namen des Nutzers, dem die Session gehört. Er erscheint also wie der eines gewöhnlichen Windows-Prozesses, was die Kompatibilität mit VPNs und Firewalls deutlich verbessern soll. Die VM schickt dazu Ethernet-Frames über eine Virtio-Queue an einen Windows-Prozess, der DNS-Anfragen beantwortet, TCP- und UDP-Verkehr routet und Ports weiterleitet.

Kontrolle für Admins

Für den Einsatz in Unternehmen erweitert Microsoft die bestehenden WSL-Anbindungen an Intune und Defender for Endpoint auf Container. Defender for Endpoint zeigt Prozess-, Datei- und Netzwerkaktivitäten aus WSL-Containern an und ordnet sie dem Windows-Host zu. Sicherheitsteams brauchen so keinen separaten Workflow für ihre Untersuchungen.

In Intune gibt es zwei neue Einstellungen. „Allow WSL containers access“ schaltet die gesamte Funktion frei oder sperrt sie. Per „WSL containers registry allow list“ legen Admins fest, aus welchen Registries Entwickler Images beziehen dürfen. So lassen sich Pulls etwa auf eine interne Registry beschränken, statt Docker Hub freizugeben.

Werkzeuge und Ausblick

Auch Drittwerkzeuge unterstützen WSLC bereits. VS Code Dev Containers kann wslc als Standardtreiber nutzen, Aspire und die Container-Erweiterung für VS Code unterstützen WSL Container ebenfalls. Aus der Community kommen das Terminal-Dashboard Lazywslc, die WinUI-3-Anwendung WSL Container Desktop zur Verwaltung von Containern, k3s-Clustern und Registries sowie das Skript WSLc remote, mit dem sich wslc aus WSL-Distributionen heraus aufrufen lässt.

Microsoft will als Nächstes an Compose-Unterstützung arbeiten, sie ist der meistgewünschte Punkt. Vorhandene compose.yaml-Dateien sollen dann unverändert funktionieren. Einen Termin nennt Microsoft nicht. Die Verbesserungen bei Dateizugriff und Netzwerk sollen außerdem nicht nur den WSL Containern zugutekommen, sondern auch WSL-Distributionen und anderen Container-Techniken, die auf WSL aufsetzen. Der Code von WSLC ist Open Source; Einstiegsbeispiele für CLI und API finden sich in der Dokumentation zu WSL Containern bei Microsoft Learn.