Am 12. August 2026 hat Docker die Public Beta von Docker VMM angekündigt: eine komplett neu gebaute Virtualisierungsschicht unter Docker Desktop, entwickelt von Docker selbst, verfügbar ab Docker Desktop 4.86 für Mac und Windows. Zur GA Ende Oktober soll Linux folgen, und Docker VMM wird dann der Standard für alle Neuinstallationen.
Ich bin seit 2023 Docker Captain und beschäftige mich beruflich seit Jahren mit Containern in Entwicklung und Betrieb. Deshalb interessiert mich an dieser Ankündigung weniger die Marketing-Zeile „best Docker Desktop has ever run“, sondern die Frage darunter: Was macht ein VMM eigentlich, warum baut Docker jetzt einen eigenen, und was heißt das für den Rechner, auf dem Sie jeden Tag docker compose up tippen?
Warum Docker Desktop überhaupt eine virtuelle Maschine braucht
Container sind keine eigenständige Technologie, sondern ein Bündel von Linux-Kernel-Funktionen: Namespaces isolieren Prozesse, Netzwerk und Dateisystem, cgroups begrenzen Ressourcen, OverlayFS stapelt Image-Layer. Ein Container ist ein ganz normaler Linux-Prozess mit einer sehr strikten Sicht auf die Welt.
Das heißt aber auch: Ohne Linux-Kernel keine Linux-Container. Auf einem Mac oder einem Windows-Rechner gibt es diesen Kernel nicht. Docker Desktop löst das seit jeher gleich: Es startet eine kleine Linux-VM, in der die Docker Engine läuft. Die CLI auf dem Host redet über einen Socket mit dieser VM, und für den Entwickler fühlt sich alles an, als liefe Docker nativ.
macOS / Windows (Host)
|
| docker CLI, Docker Desktop UI
|
+-- VMM (Virtual Machine Monitor)
|
+-- Linux-VM
|
+-- Docker Engine (dockerd, containerd, runc)
|
+-- Container A
+-- Container B
+-- ...Die Komponente, die diese VM erzeugt, betreibt und mit dem Host verbindet, ist der VMM. Und genau dort setzt die Ankündigung an.
Was ein VMM ist
VMM steht für Virtual Machine Monitor. Der Begriff ist älter als das Wort Hypervisor und meint im Kern dasselbe: eine Software, die einer virtuellen Maschine vorspielt, sie hätte eigene Hardware. Ein VMM hat drei Aufgaben.
CPU und Speicher virtualisieren. Der Gast-Kernel soll glauben, er laufe direkt auf dem Prozessor. Moderne CPUs bringen dafür Hardware-Unterstützung mit (Intel VT-x, AMD-V, auf Apple Silicon die Virtualisierungserweiterungen der ARM-Architektur). Der VMM nutzt diese Erweiterungen, um Gast-Code fast ohne Geschwindigkeitsverlust auszuführen, und fängt nur die Befehle ab, die der Gast nicht selbst ausführen darf.
Geräte bereitstellen. Eine VM braucht Netzwerkkarte, Festplatte, Uhr, Zufallszahlen und eine Verbindung zum Dateisystem des Hosts. Diese Geräte sind Software. Der Quasi-Standard dafür ist virtio: Der Gast-Kernel spricht einen schlanken, virtualisierungsfreundlichen Treiber an, der VMM setzt die Anfragen in echte Host-Operationen um. Für Dateifreigaben zwischen Host und Container ist virtiofs relevant, und wer je ein node_modules-Verzeichnis über eine Bind-Mount-Grenze hinweg gebaut hat, weiß, wie sehr die Qualität dieser Schicht den Alltag bestimmt.
Den Lebenszyklus steuern. Starten, anhalten, Speicher hinzufügen oder zurückgeben, sauber herunterfahren. Hier entscheidet sich, ob Docker Desktop nach dem Aufwachen des Laptops in zwei Sekunden oder in zwanzig wieder da ist und ob die VM 8 GB RAM blockiert, obwohl kein Container läuft.
Wichtig für die Einordnung: Auf macOS darf kein Drittanbieter direkt auf die Virtualisierungserweiterungen der CPU zugreifen. Jeder VMM, auch der von Docker, setzt dort auf Apples Hypervisor.framework auf. Das Framework übernimmt die unterste Ebene (CPU und Speicher), der VMM baut darauf die Geräte, den Bootvorgang und alles Weitere. Unter Windows gilt das Gleiche mit der Windows Hypervisor Platform, die die Release Notes von 4.86 auch ausdrücklich als Voraussetzung nennen. Docker VMM ist also kein Hypervisor, der Apple oder Microsoft verdrängt. Es ist die Schicht dazwischen, und die war bisher nie von Docker.
Eine kurze Geschichte der VMMs unter Docker Desktop
Wer Docker länger nutzt, hat diese Schicht schon mehrfach wechseln sehen:
| Zeitraum | Mac | Windows |
|---|---|---|
| bis 2016 | VirtualBox (Docker Toolbox) | VirtualBox (Docker Toolbox) |
| ab 2016 | HyperKit auf Basis von xhyve/bhyve | Hyper-V |
| ab 2020 | weiterhin HyperKit | WSL 2 als Standard |
| ab 2021/2022 | Apple Virtualization Framework | unverändert |
| ab 4.35 (Nov. 2024) | Docker VMM Beta, auf Basis von libkrun | unverändert |
| ab 4.86 (Aug. 2026) | Docker VMM, neu gebaut | Docker VMM, neu gebaut |
Jeder dieser Wechsel hatte einen konkreten Grund. HyperKit war lange Zeit die einzige brauchbare Option, kam aber mit Apple Silicon an sein Ende. Das Apple Virtualization Framework brachte native ARM-Unterstützung und später Rosetta für amd64-Images in der VM, aber Docker hat auf die Weiterentwicklung keinen Einfluss. Die erste Docker-VMM-Generation von 2024 nutzte mit libkrun eine schlanke, in Rust geschriebene Bibliothek aus dem Umfeld von Red Hat und Podman. Docker zeigte damals in einem eigenen Benchmark, dass ein git status auf einem großen, per Bind Mount eingehängten Repository von rund 27 Sekunden auf unter 10 Sekunden fiel, im warmen Cache von rund 3 Sekunden auf unter eine.
Diese Zahlen stammen aus der ersten Generation. Für die neue, komplett neu geschriebene Engine nennt Docker im Ankündigungsbeitrag bisher keine Messwerte, sondern spricht von „measurably faster“ und „significantly faster“. Das ist ein Punkt, an dem ich mir mehr Transparenz wünschen würde. Dazu unten mehr.
Was Docker mit dem Neubau verspricht
Der Blogpost von Deanna Sparks und Colin Hemmings nennt fünf Bereiche.
Schnellerer Start. Vom ersten Launch über den Wechsel zwischen Projekten bis zum Wiederanlauf nach einem Absturz. Wer morgens Docker Desktop startet und dann Kaffee holt, kennt das Problem.
Schnelleres Dateisystem. Die Dateifreigabe zwischen Host und Container soll deutlich schneller sein. Das ist für Entwickler mit Hot Reload, Watch-Modus oder großen Monorepos der wichtigste Punkt überhaupt.
Speicher zurückgeben. Docker VMM gibt Arbeitsspeicher an den Host zurück, wenn Container idle sind. Bisher hielt die VM die zugewiesene Menge fest, egal ob sie gebraucht wurde. Auf einem 16-GB-MacBook mit einer 8-GB-Docker-VM ist das der Unterschied zwischen einem flüssigen und einem swappenden System.
Ein Hypervisor für Windows von Docker. Bisher war Docker auf Windows entweder auf WSL 2 oder Hyper-V angewiesen, beides von Microsoft. Jetzt gibt es erstmals eine Variante, deren Fehler Docker selbst beheben kann. Docker beschreibt das Ziel als „die Isolation von Hyper-V mit der Geschwindigkeit von WSL 2“.
Gleicher Unterbau auf allen Plattformen. Im Blogpost steht der Satz, der mich am meisten interessiert:
„That means we own the full stack, and we can tune every part of the engine for container workloads specifically.“
Deanna Sparks und Colin Hemmings, Docker
Ein generischer VMM muss beliebige Gäste ausführen können: Windows-VMs, Desktop-Linux, alte Kernel. Docker VMM muss genau einen Gast ausführen, nämlich Dockers eigenen Linux-Kernel mit der Docker Engine. Alles, was ein universeller VMM an Kompatibilität mitschleppt, kann hier wegfallen. Das ist die eigentliche Idee hinter dem Neubau.
Voraussetzungen und Einschalten
Die Dokumentation zu Docker VMM ist kurz und klar. Sie brauchen:
- Docker Desktop 4.86 oder neuer (Release Notes)
- auf dem Mac einen Apple-Silicon-Rechner
- unter Windows eine funktionierende Windows Hypervisor Platform
- mindestens 4 GB RAM, die der Docker-VM zugewiesen sind
Einschalten geht auf beiden Plattformen gleich: Settings, General, Virtual Machine Manager, dort Docker VMM auswählen, dann Apply & restart. Wer auf dem Mac schon die erste Docker-VMM-Generation aktiv hatte, wurde mit dem Update auf 4.86 automatisch auf die neue Engine umgestellt. Auf Windows ist es ein bewusstes Opt-in.
Zurückwechseln geht an derselben Stelle. Das ist während einer Beta ein wichtiger Satz.
Die Einschränkungen, die man vorher kennen sollte
Die Docs nennen drei Punkte, die ich hier ausdrücklich wiederhole, weil sie über Erfolg oder Frust der ersten Woche entscheiden.
Kein Rosetta. Docker VMM unterstützt auf dem Mac keine Rosetta-Emulation in der Linux-VM. Wer amd64-Images auf Apple Silicon ausführt, weil es das Image nur so gibt oder weil Produktion auf x86 läuft, fällt auf QEMU-Emulation zurück. Und die ist langsam. Das Apple Virtualization Framework bleibt hier die bessere Wahl.
Bind Mounts werden nicht automatisch freigegeben. Verzeichnisse, die Sie in Container einhängen, müssen unter File Sharing explizit freigegeben sein. Das war beim Apple Framework bequemer.
Datenbanken auf virtiofs. Die Docs warnen ausdrücklich, dass Datenbanken wie MongoDB oder Cassandra auf per virtiofs eingehängten Verzeichnissen fehlschlagen können. Datenbank-Daten gehören ohnehin in ein benanntes Volume und nicht in einen Bind Mount, aber in Entwicklungsumgebungen sieht man das Gegenteil öfter, als man denkt.
Aus den Release Notes lohnt außerdem ein Blick auf zwei Details: In 4.86 wurde eine Regression behoben, bei der der eingehende Netzwerkdurchsatz von Containern auf rund 0,3 GB/s eingebrochen war, und Docker VMM kann auf dem Mac jetzt mehr als 28 GiB Host-Speicher nutzen. Beides zeigt, dass die Beta genau das ist: eine Beta, an der aktiv gearbeitet wird.
Meine Einschätzung als Docker Captain
Ich halte die Entscheidung für richtig, und zwar aus einem Grund, der über Performance hinausgeht.
Docker Desktop war jahrelang ein Produkt, dessen wichtigste Komponente Docker nicht gehörte. Wenn das Apple Virtualization Framework mit einem macOS-Update ein Verhalten änderte, konnte Docker nur reagieren. Wenn WSL 2 unter Windows Speicher nicht freigab, war das ein Microsoft-Ticket. Mit einem eigenen VMM hat Docker die Schicht, in der die meisten „Docker Desktop ist langsam“-Beschwerden tatsächlich entstehen, erstmals selbst in der Hand. Dass Docker den Beitrag mit Speicherrückgabe, Dateisystem und Startzeit beginnt und nicht mit einem neuen Dashboard, zeigt, dass die richtigen Leute daran arbeiten.
Drei Dinge würde ich mir trotzdem wünschen.
Zahlen. Der Blogpost von 2024 hatte konkrete Messwerte. Der von 2026 hat Adjektive. Für ein Beta-Programm, das um Feedback aus echten Workflows bittet, wären reproduzierbare Benchmarks die bessere Einladung.
Rosetta. Für viele Teams ist der Mac die Entwicklungsmaschine und x86 die Produktion. Solange Docker VMM kein Rosetta kann, ist es für diese Teams keine Option, egal wie schnell das Dateisystem ist. Ich gehe davon aus, dass das vor der GA kommt, finde aber im Beitrag keine Zusage.
Linux. Docker Desktop auf Linux nutzt bisher KVM und QEMU, beides ausgereift und offen. Ich bin gespannt, ob Docker VMM dort einen messbaren Vorteil bringt oder ob es eher um einheitliche Governance geht. Der Beitrag deutet mit „enterprise admin controls“ eher Letzteres an.
Was ich Teams jetzt empfehle
Wechseln Sie, wenn:
- Ihre Images arm64-nativ sind oder Multi-Arch-Builds haben
- Ihr Alltag von Bind Mounts mit vielen kleinen Dateien geprägt ist (Node, PHP, Python, Monorepos)
- Sie unter Windows bisher zwischen WSL 2 und Hyper-V hin- und hergewechselt haben
Warten Sie, wenn:
- Sie auf amd64-Images angewiesen sind und Rosetta brauchen
- Sie Datenbanken in Bind Mounts betreiben und das kurzfristig nicht ändern wollen
- Ihr Team eine Beta grundsätzlich nicht auf Arbeitsgeräten laufen lässt
Und in jedem Fall: Messen Sie. Ein time docker compose up vor und nach dem Umschalten, ein Build Ihres größten Projekts, ein git status im gemounteten Repo. Fünf Minuten Aufwand, und Sie wissen, ob die Beta für Sie etwas bringt. Wenn nicht, ist der Weg zurück ein Klick. Und wenn etwas hakt, nutzt Docker das Feedback in der App tatsächlich. Ich habe das in den letzten Jahren mehrfach erlebt.
Ausblick
Docker beschreibt Docker VMM als Fundament für alles Weitere: Docker Sandboxes für KI-Agenten sitzen bereits darauf, und die langfristige Vision ist eine einheitliche Runtime für Laptop, Cloud und On-Premise, in der Container, Compose-Anwendungen und Agenten gleichberechtigt laufen.
Das passt zu einem Thema, das mich in diesem Blog noch öfter beschäftigen wird: Wer KI-Agenten mit Shell und Netzwerkzugriff betreibt, braucht eine Isolationsschicht, die er versteht und kontrolliert. Dass Docker diese Schicht jetzt selbst baut, ist aus dieser Sicht mehr als ein Performance-Update.
Weiterlesen
- Ankündigung der Public Beta (Docker Blog, 12. August 2026) und Dokumentation zu Docker VMM
- Docker Desktop Release Notes, insbesondere 4.86.0 vom 10. August 2026
- Docker Desktop 4.35, die erste Docker-VMM-Beta, und die Benchmarks der ersten Generation
- Docker Sandboxes, das erste Produkt auf dem neuen VMM, und mein Beitrag zu microVMs und Containern
- Docker Captains
- Fragen zu Docker VMM oder Container-Setups in Ihrem Team? Schreiben Sie mir.
