Docker Desktop 4.86 f\u00fchrt 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\u00df mehr \u00fcber die Details und die Roadmap.<\/p>\n
Weiterlesen nach der Anzeige<\/p>\n
<\/p>\n
\n Colin Hemmings ist Senior Product Manager bei Docker Inc. und der leitende Produktmanager f\u00fcr den Docker Desktop.\n <\/p>\n
Warum waren die bisherigen Virtualisierungsl\u00f6sungen nicht gut genug?<\/p>\n
Es ging nicht darum, dass die bisherigen Virtualisierungsl\u00f6sungen nicht gut genug waren. Apples Virtualization.framework, WSL 2 und Hyper-V sind allesamt hervorragende Technologien, und wir haben jede bewusst ausgew\u00e4hlt. Darum ging es bei der jetzigen Umstellung nicht. Es ging vielmehr um die vielen Vorteile, die wir den Kunden mit der Neuausrichtung bieten k\u00f6nnen.<\/p>\n
Die Aufgabe von Docker Desktop ist es, Entwicklerinnen und Entwicklern eine verwaltete Umgebung f\u00fcr die Ausf\u00fchrung von Containern bereitzustellen. Die VM ist dabei ein Implementierungsdetail, \u00fcber das Entwickler nicht nachdenken m\u00fcssen. Wie sie sich verh\u00e4lt, liegt vielmehr in unserer Verantwortung: Wie schnell sie startet, wie viel sie vom Rechner beansprucht und wie sie unter Last standh\u00e4lt. Docker hatte den Gro\u00dfteil dieser Umgebung bereits aufgebaut, einschlie\u00dflich LinuxKit f\u00fcr das VM-Image sowie unsere eigenen Dienste f\u00fcr Netzwerk und Dateifreigabe. Das einzige wesentliche Bauteil, das wir bisher nicht selbst entwickelt hatten, war der zugrunde liegende VMM.<\/p>\n
Jetzt, durch die neue Eigenentwicklung, k\u00f6nnen wir den VMM speziell f\u00fcr Container-Workloads tunen und diese Verbesserungen unserem eigenen Zeitplan folgend ausliefern. Au\u00dferdem verf\u00fcgen wir dann \u00fcber eine einheitliche Virtualisierungsschicht f\u00fcr macOS, Windows und Linux. So ist deren Verhalten unabh\u00e4ngig von den Arbeitsumgebungen der Entwickler konsistent. Das schafft uns eine Grundlage, auf der wir weiter aufbauen k\u00f6nnen.<\/p>\n
Au\u00dferdem 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\u00fcck, wenn Container im Leerlauf sind. Speicher ist ein gutes Beispiel f\u00fcr 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\u00fcckgeben k\u00f6nnen. Der Footprint von Desktop entspricht der wirklichen Nutzung der Container.<\/p>\n
Aus technischer Sicht wurde Docker VMM von Grund auf in Rust geschrieben und l\u00e4uft direkt auf der nativen Hypervisor-Schnittstelle der jeweiligen Plattform. Das ist Hypervisor-Framework unter macOS, der Windows Hypervisor und KVM unter Linux \u2013 nur eine Codebasis f\u00fcr alle drei. Die gleiche Engine betreibt auch Docker Sandboxes, unsere isolierten Umgebungen f\u00fcr Agenten und nicht vertrauensw\u00fcrdige Workloads.<\/p>\n
Weiterlesen nach der Anzeige<\/p>\n
Bewusst eng gehalten ist das Ger\u00e4temodell. Wir implementieren nur die paravirtualisierten Ger\u00e4te, die Container-Workloads tats\u00e4chlich nutzen, anstatt eine breite Palette an Hardware zu emulieren. Das sind virtio-fs f\u00fcr die Dateifreigabe, virtio-net f\u00fcr die Netzwerkkommunikation und virtio-balloon f\u00fcr den Speicher. Hinzu kommt nur das Minimum, das ein Linux-Gast f\u00fcr den Start ben\u00f6tigt.<\/p>\n
<\/p>\n
Mehr zu Agentic AI, digitaler Souver\u00e4nit\u00e4t und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz<\/a> vom 11. bis 12. November 2026 in Mannheim.<\/p>\n