Drei Fragen und Antworten: Mehr Effizienz und Speed mit dem neuen Docker-VMM

Docker Desktop 4.86 führt die neue, von Docker selbst entwickelte Virtualisierungsschicht Docker Virtual Machine Manager (VMM) ein. Er soll effizienter, schneller und besser zu managen sein als die bisherigen Komponenten der Betriebssysteme. Docker VMM ersetzt die bisherigen Virtualisierungen libkrun unter macOS und WSL 2 unter Windows. Colin Hemmings, Senior Product Manager bei Docker, weiß mehr über die Details und die Roadmap. Colin Hemmings Colin Hemmings ist Senior Product Manager bei Docker Inc. und der leitende Produktmanager für den Docker Desktop. Warum waren die bisherigen Virtualisierungslösungen nicht gut genug? Es ging nicht darum, dass die bisherigen Virtualisierungslösungen nicht gut genug waren. Apples Virtualization.framework, WSL 2 und Hyper-V sind allesamt hervorragende Technologien, und wir haben jede bewusst ausgewählt. Darum ging es bei der jetzigen Umstellung nicht. Es ging vielmehr um die vielen Vorteile, die wir den Kunden mit der Neuausrichtung bieten können. Die Aufgabe von Docker Desktop ist es, Entwicklerinnen und Entwicklern eine verwaltete Umgebung für die Ausführung von Containern bereitzustellen. Die VM ist dabei ein Implementierungsdetail, über das Entwickler nicht nachdenken müssen. Wie sie sich verhält, liegt vielmehr in unserer Verantwortung: Wie schnell sie startet, wie viel sie vom Rechner beansprucht und wie sie unter Last standhält. Docker hatte den Großteil dieser Umgebung bereits aufgebaut, einschließlich LinuxKit für das VM-Image sowie unsere eigenen Dienste für Netzwerk und Dateifreigabe. Das einzige wesentliche Bauteil, das wir bisher nicht selbst entwickelt hatten, war der zugrunde liegende VMM. Jetzt, durch die neue Eigenentwicklung, können wir den VMM speziell für Container-Workloads tunen und diese Verbesserungen unserem eigenen Zeitplan folgend ausliefern. Außerdem verfügen wir dann über eine einheitliche Virtualisierungsschicht für macOS, Windows und Linux. So ist deren Verhalten unabhängig von den Arbeitsumgebungen der Entwickler konsistent. Das schafft uns eine Grundlage, auf der wir weiter aufbauen können. Außerdem konnten wir ein paar konkreten Verbesserungen erzielen, zum Beispiel einen messbar schnelleren Start von Containern, und zwar sowohl beim ersten Start, als auch beim Projektwechsel und bei der Wiederherstellung nach einem Neustart. Der deutlich schnellere Dateiaustausch zwischen Container und Host beschleunigt jeden Build. Und die intelligentere Speicherverwaltung gibt dem Host RAM zurück, wenn Container im Leerlauf sind. Speicher ist ein gutes Beispiel für die Vorteile: VMM nutzt die Funktion Free Page Reporting, mit der ein Gastkernel kontinuierlich die von ihm freigegebenen Pages meldet, sodass wir diesen Speicherplatz fortlaufend dem Host zurückgeben können. Der Footprint von Desktop entspricht der wirklichen Nutzung der Container. Aus technischer Sicht wurde Docker VMM von Grund auf in Rust geschrieben und läuft direkt auf der nativen Hypervisor-Schnittstelle der jeweiligen Plattform. Das ist Hypervisor-Framework unter macOS, der Windows Hypervisor und KVM unter Linux – nur eine Codebasis für alle drei. Die gleiche Engine betreibt auch Docker Sandboxes, unsere isolierten Umgebungen für Agenten und nicht vertrauenswürdige Workloads. Bewusst eng gehalten ist das Gerätemodell. Wir implementieren nur die paravirtualisierten Geräte, die Container-Workloads tatsächlich nutzen, anstatt eine breite Palette an Hardware zu emulieren. Das sind virtio-fs für die Dateifreigabe, virtio-net für die Netzwerkkommunikation und virtio-balloon für den Speicher. Hinzu kommt nur das Minimum, das ein Linux-Gast für den Start benötigt. CLC 2026: Konferenz für DevEx und Platform Engineering Mehr zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim. ☞ Sichern Sie sich jetzt die Tickets zum Frühbucherpreis. ☜ Wie müssen sich Entwickler anpassen? Für die meisten Entwickler ändert sich so gut wie nichts. VMM läuft unterhalb der Docker-Engine, sodass Engine, CLI, API, Images, Volumes, Netzwerke und Compose unverändert bleiben. Es gibt keine neue Syntax und nichts muss umgeschrieben werden. Neben den bereits vorhandenen erscheint eine zusätzliche Option in den Einstellungen von Docker Desktop, wobei man jederzeit zurückwechseln kann. macOS-Entwickler, die bereits die bestehende Docker-VMM-Option nutzen, werden automatisch umgestellt. In dieser Beta läuft Docker VMM auf Apple-Silicon-Macs und Windows x86. Linux folgt erst mit der allgemeinen Verfügbarkeit. Ein Hinweis zu Windows: Docker VMM läuft in einer eigenen virtuellen Maschine mit eigenem Datenträger, sodass Images und Container aus dem vorhandenen Backend dort nicht erscheinen. Alles, was man nutzen möchten, sollte man in eine Registry übertragen oder neu bauen. Das bestehende Backend bleibt unberührt, wenn man zurückwechselt. Unter macOS wird der Datenträger gemeinsam genutzt, sodass nichts verschoben werden muss. Zwei Funktionen, gibt es derzeit weder in der Beta noch in der endgültigen Version, sie liegen aber auf der Roadmap für kommende Versionen. In beiden Fällen funktioniert das bestehende Backend weiterhin genau wie bisher: Zum einen soll eine GPU-Unterstützung kommen. Derzeit läuft CUDA unter Windows über den WSL-2-eigenen GPU-Passthrough und nicht über die Virtualisierungsschicht. Für Anwender, die bei WSL-2 bleiben, ändert sich an den GPU-Workloads nichts. Zum Anderen die Rosetta-Unterstützung auf Apple Silicon: Docker Desktop unterstützt Rosetta nur bei x86-Workloads, was für Apples Virtualization.framework spezifisch ist. Eine Emulation mit Docker VMM funktioniert zwar zum Beispiel mit docker run --platform linux/amd64, sie verwendet jedoch QEMU, was langsamer ist. Entwickler, die regelmäßig amd64-Images erstellen und die Leistung von Rosetta benötigen, sollten die unveränderte Option Apple Virtualization VMM verwenden. Ähnliches gilt, wenn man die WSL-Integration von Docker Desktop nutzt, um die Docker-CLI innerhalb der eigenen WSL-Distributionen auszuführen – dies ist an das WSL-2-Backend gebunden. Was sind die nächsten Schritte, und was können Entwickler erwarten? Die Beta-Phase läuft bis in den Herbst hinein, und sehr nützlich sind für uns konkrete, reproduzierbare Berichte über Workloads, die sich anders als erwartet verhalten. Die allgemeine Verfügbarkeit ist derzeit für Ende Oktober geplant. Dann wird Linux zu den unterstützten Plattformen hinzugefügt und Docker VMM wird zur Standard-Virtualisierungsschicht für neue Docker-Desktop-Installationen. Bestehende Installationen werden nicht migriert und man verbleibt bei dem, was man gewählt hat, aber man kann Docker VMM jederzeit zum Ausprobieren aktivieren. Vor der allgemeinen Verfügbarkeit werden wir einen umfassenden Satz an Benchmarks zusammen mit der dahinterstehenden Methodik veröffentlichen. Sie gehen dabei über Docker VMM hinaus, denn wir meinen, dass Entwickler über eine einheitliche, transparente Methode zur Messung der Container-Leistung verfügen sollten. Die Kontrolle über die Virtualisierung eröffnet uns zwei Richtungen für weitere Entwicklungen: Die erste ist eine engere Integration des Host mit der Containerumgebung. Da wir die Virtualisierungsschicht kontrollieren, können wir Host-Ressourcen und Entwickler-Tools direkt mit ihr verbinden, sodass die von den Entwicklern bereits genutzten Tools mit ihren Containern zusammenarbeiten können. Bei dieser Geschichte geht es vor allem um Produktivität und Troubleshooting. Die zweite Richtung ist die Kontrolle über die Isolation. Eine VM-Grenze um Container-Workloads ist für viele Unternehmen wichtig, insbesondere jetzt, da Entwickler KI-Agenten und deren erzeugter Code lokal ausführen. Da wir diese Schicht jetzt kontrollieren, Anwender explizit entscheiden und steuern, was diese Grenze überschreitet darf. Beides sind zum jetzigen Zeitpunkt noch strategische Ausrichtungen und keine terminierten Feature-Zusagen, aber sie sind ein wesentlicher Grund dafür, dass wir in die Kontrolle dieser Ebene investiert haben.