Virtuelle Maschinen vs. Docker — der Unterschied einfach erklärt

„Sollen wir das in einer VM oder in Docker betreiben?" — diese Frage taucht in fast jedem IT- und IoT-Projekt auf. Beide schaffen isolierte, reproduzierbare Umgebungen, lösen das Problem aber grundverschieden. Dieser Beitrag erklärt den Unterschied verständlich und zeigt, wann sich was lohnt.

Was ist eine virtuelle Maschine?

Eine virtuelle Maschine (VM) ist ein vollständiger, simulierter Computer in der Software. Ein sogenannter Hypervisor teilt die physische Hardware in mehrere virtuelle Maschinen auf. Jede VM bekommt eigene virtuelle CPU, eigenen Arbeitsspeicher, eigene Festplatte — und vor allem ein eigenes, komplettes Betriebssystem (das „Gast-OS").

Typ-1-Hypervisor. Läuft direkt auf der Hardware (z. B. Proxmox, ESXi) — typisch im Server-/Rechenzentrumsbetrieb.

Typ-2-Hypervisor. Läuft als Programm auf einem Betriebssystem (z. B. VirtualBox) — typisch auf dem Arbeitsplatz.

Was ist ein Container (Docker)?

Ein Container verpackt eine Anwendung samt ihren Abhängigkeiten (Bibliotheken, Konfiguration) in eine isolierte Einheit. Der entscheidende Unterschied: Ein Container bringt KEIN eigenes Betriebssystem mit. Stattdessen teilen sich alle Container den Kernel des Host-Systems. Docker ist die bekannteste Technologie dafür; die Isolation übernehmen Linux-Bordmittel wie Namespaces und cgroups.

Der zentrale Unterschied: Kernel teilen vs. komplettes OS

Auf den Punkt gebracht: Eine VM virtualisiert die Hardware — darauf läuft pro VM ein vollständiges Betriebssystem. Ein Container virtualisiert das Betriebssystem — er nutzt den Kernel des Hosts mit und enthält nur die Anwendung plus ihre Bibliotheken. Genau daraus ergeben sich alle weiteren Unterschiede.

Die Unterschiede im Detail

Grösse. VM-Images sind oft mehrere Gigabyte gross (ganzes OS), Container-Images meist nur Megabyte.

Startzeit. Eine VM muss ein OS booten (Sekunden bis Minuten); ein Container startet quasi sofort.

Overhead. Jede VM trägt die volle Last ihres Gast-OS; Container teilen den Kernel und brauchen daher viel weniger Ressourcen.

Isolation. VMs trennen auf Hardware-/Hypervisor-Ebene — sehr stark. Container trennen auf Prozess-/Kernel-Ebene — leichter, aber weniger hart.

Dichte. Auf demselben Server laufen nur wenige VMs, aber sehr viele Container.

Portabilität. Ein Container-Image läuft überall gleich, wo eine Container-Engine vorhanden ist — „läuft bei mir" wird zu „läuft überall".

Wann VM, wann Docker?

Eher VM, wenn … du ein anderes Betriebssystem oder einen anderen Kernel brauchst, eine sehr starke Isolation nötig ist (Sicherheit, mehrere Mandanten), oder Legacy-Software bzw. komplette eigenständige Systeme laufen sollen.

Eher Docker, wenn … du moderne Anwendungen/Microservices schnell ausrollen und skalieren willst, viele Instanzen auf wenig Hardware brauchst (CI/CD, Edge) und auf einer gemeinsamen Linux-Basis arbeitest.

Und im IoT/OT-Umfeld?

Am Netzrand zählt jedes Megabyte und jede Sekunde Startzeit: Auf IoT-Gateways und Edge-Geräten sind Container oft die bessere Wahl, weil sie schlank sind und sich leicht aktualisieren lassen. VMs spielen ihre Stärke dort aus, wo harte Trennung gefragt ist — etwa um eine ältere Steuerungs-Software sauber gekapselt weiterzubetreiben oder kritische Bereiche strikt voneinander zu isolieren.

Fazit

VMs und Container sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Aufgaben. Wer den Kernunterschied verstanden hat — eigenes Gast-OS gegenüber geteiltem Kernel — trifft die Wahl schnell und richtig: VM für maximale Trennung und Sonderfälle, Docker für leichte, schnelle, gut skalierbare Anwendungen. Und im Zweifel: beides zusammen.