Docker vs LXC vs VM: Wann welche Virtualisierung?

Wer IT-Infrastruktur plant, steht früher oder später vor der Frage: Virtuelle Maschine, LXC-Container oder Docker? Alle drei Technologien isolieren Workloads — aber auf fundamental unterschiedliche Weise. Die richtige Wahl hängt von Sicherheitsanforderungen, Performance-Zielen und dem konkreten Einsatzzweck ab. Dieser Artikel vergleicht die drei Ansätze und zeigt, wann sich welche Lösung lohnt.

Drei Ansätze, ein Ziel

Virtualisierung bedeutet, Ressourcen von der physischen Hardware zu abstrahieren. Die drei gängigen Methoden unterscheiden sich in der Tiefe dieser Abstraktion:

• Virtuelle Maschinen (KVM/QEMU) emulieren komplette Hardware. Jede VM läuft mit einem eigenen Kernel, eigenem Bootloader und eigenen Treibern — vollständig isoliert vom Host.
• LXC-Container teilen sich den Kernel des Host-Systems, isolieren aber Dateisystem, Netzwerk und Prozesse über Linux-Namespaces und cgroups. Sie verhalten sich wie leichtgewichtige virtuelle Maschinen.
• Docker/OCI-Container nutzen ebenfalls Namespaces und cgroups, sind aber auf einzelne Anwendungen zugeschnitten. Ein Docker-Container verpackt eine Applikation mit all ihren Abhängigkeiten in ein portables Image.

Virtuelle Maschinen: Maximale Isolation

VMs bieten die stärkste Isolation, da jede Instanz einen eigenen Kernel ausführt. Ein kompromittierter Kernel innerhalb einer VM hat keinen Zugriff auf den Host oder andere VMs. Das macht VMs zur ersten Wahl für Multi-Tenant-Umgebungen, sicherheitskritische Workloads und Betriebssysteme, die nicht auf Linux basieren.

Vorteile: Vollständige Kernel-Isolation, beliebige Betriebssysteme (Windows, BSD, Linux), ausgereifte Live-Migration, unabhängige Kernel-Updates.

Nachteile: Höherer Ressourcenverbrauch (eigener Kernel, RAM-Overhead von 256–512 MB pro VM), längere Startzeiten (30–90 Sekunden), größere Disk-Images.

LXC-Container: Das Beste aus beiden Welten

LXC-Container starten ein vollständiges Linux-Userland — inklusive Init-System, Paketmanager und SSH — aber ohne eigenen Kernel. Sie starten in 1–3 Sekunden, verbrauchen kaum mehr Ressourcen als die Dienste selbst und lassen sich wie klassische Server verwalten.

Vorteile: Near-native Performance, minimaler Overhead (kein Kernel-Duplikat), schneller Start, einfache Verwaltung über Proxmox.

Nachteile: Nur Linux-Gäste, geteilter Kernel (Sicherheitsimplikation), eingeschränkte Kernel-Modul-Nutzung, kein eigenständiges Kernel-Update.

Docker/OCI-Container: Applikationsfokus

Docker verpackt eine einzelne Anwendung mit ihren Abhängigkeiten in ein standardisiertes Image. Container werden nicht wie Server verwaltet, sondern deklarativ über docker-compose.yml oder Kubernetes-Manifeste definiert. Sie sind kurzlebig, reproduzierbar und ideal für Microservices.

Vorteile: Höchste Portabilität, riesiges Image-Ökosystem (Docker Hub), Infrastructure-as-Code, schnelle Skalierung, Startup in unter einer Sekunde.

Nachteile: Nicht für zustandsbehaftete Dienste ohne Volumes geeignet, Netzwerk-Komplexität bei Multi-Host-Setups, geteilter Kernel, weniger geeignet für klassische Systemadministration.

Vergleichstabelle

Merkmal	VM (KVM/QEMU)	LXC-Container	Docker/OCI
Isolation	Vollständig (eigener Kernel)	Namespace-basiert (geteilter Kernel)	Namespace-basiert (geteilter Kernel)
Performance	~95 % nativ	~99 % nativ	~99 % nativ
RAM-Overhead	256–512 MB pro VM	5–20 MB pro Container	5–15 MB pro Container
Startzeit	30–90 Sekunden	1–3 Sekunden	< 1 Sekunde
Betriebssysteme	Linux, Windows, BSD	Nur Linux	Nur Linux
Persistenz	Vollständiges Disk-Image	Persistentes Rootfs	Ephemeral (Volumes nötig)
Netzwerk	Virtuelle NICs (Bridge/VLAN)	veth-Paare (Bridge/VLAN)	Docker-Netzwerk (NAT/Bridge)
Einsatzzweck	Legacy-Apps, Windows, Compliance	Linux-Dienste, Hosting, Infra	Microservices, CI/CD, Apps
Proxmox-Support	Nativ (KVM)	Nativ (LXC)	In LXC oder VM

Wann welche Technologie?

Die Entscheidung folgt einer einfachen Logik:

VM wählen, wenn:

• Windows oder ein Nicht-Linux-OS benötigt wird
• Maximale Isolation gefordert ist (Compliance, Multi-Tenant)
• Der Workload eigene Kernel-Module erfordert
• Live-Migration zwischen Hosts essenziell ist

LXC wählen, wenn:

• Linux-Dienste mit möglichst wenig Overhead laufen sollen
• Der Container wie ein klassischer Server verwaltet wird
• Proxmox die Verwaltungsplattform ist
• Performance entscheidend ist (Datenbankserver, Fileserver)

Docker wählen, wenn:

• Anwendungen portabel und reproduzierbar sein müssen
• Microservice-Architekturen umgesetzt werden
• CI/CD-Pipelines automatisierte Deployments erfordern
• Das Ökosystem vorgefertigter Images genutzt werden soll

Kombinierte Ansätze

In der Praxis schließen sich die Technologien nicht gegenseitig aus. Gängige Kombinationen:

Docker in LXC: Ein LXC-Container mit aktiviertem Nesting (features: nesting=1) kann Docker ausführen. Proxmox verwaltet den LXC-Container, Docker verwaltet die Anwendungen darin. Diese Kombination bietet niedrigen Overhead bei gleichzeitiger Nutzung des Docker-Ökosystems — ideal für Homeserver und kleine Produktivumgebungen.

Docker in VM: Für maximale Isolation läuft Docker innerhalb einer vollständigen VM. Das ist der empfohlene Ansatz für Multi-Tenant-Plattformen oder wenn Container nicht-vertrauenswürdigen Code ausführen.

Proxmox-Integration

Proxmox VE unterstützt VMs (KVM) und LXC-Container nativ über dieselbe Weboberfläche. Beide Typen lassen sich mit Backups, Snapshots, HA-Clustering und Live-Migration verwalten. Docker wird nicht direkt von Proxmox verwaltet, sondern läuft innerhalb einer VM oder eines LXC-Containers.

Ein typisches Proxmox-Setup in der Praxis: Sicherheitskritische Dienste wie Firewalls und Datenbanken laufen in VMs, Infrastrukturdienste wie DNS, DHCP und Reverse-Proxies in LXC-Containern, und Anwendungen wie Wikis, Monitoring oder Ticketsysteme als Docker-Container innerhalb eines LXC-Containers.

Sicherheit: Kernel-Sharing verstehen

Der wichtigste Sicherheitsunterschied: LXC und Docker teilen sich den Kernel des Hosts. Eine Kernel-Schwachstelle betrifft potenziell alle Container. VMs hingegen isolieren auch den Kernel — ein Kernel-Exploit innerhalb einer VM bleibt auf diese VM beschränkt.

Für Container gelten daher zusätzliche Härtungsmaßnahmen: unprivilegierte Container verwenden, AppArmor/seccomp-Profile aktivieren, Capabilities einschränken und den Host-Kernel stets aktuell halten. In Proxmox laufen LXC-Container standardmäßig unprivilegiert — ein sinnvoller Standard.

Ressourcen-Overhead im Vergleich

Auf einem Host mit 64 GB RAM und 16 CPU-Kernen ergibt sich folgender Unterschied: Mit VMs lassen sich typischerweise 10–15 Instanzen betreiben, bevor der RAM erschöpft ist. Mit LXC-Containern sind es 50–100 Instanzen, da der Overhead pro Container minimal ist. Docker-Container skalieren ähnlich wie LXC, wobei der tatsächliche Verbrauch stark von der Anwendung abhängt.

Monitoring mit DATAZONE Control

Unabhängig von der gewählten Technologie ist zentrales Monitoring essenziell. DATAZONE Control überwacht VMs, LXC-Container und Docker-Container in einer einheitlichen Oberfläche. CPU, RAM, Storage und Netzwerk-Traffic aller drei Virtualisierungstypen fließen in ein gemeinsames Dashboard — inklusive Alerting bei Ressourcenengpässen, fehlgeschlagenen Containern oder ungewöhnlichem Verhalten.

---

Sie planen eine Virtualisierungsumgebung und brauchen Unterstützung bei der Architektur? Kontaktieren Sie uns — wir beraten Sie zur optimalen Kombination von VMs, Containern und Docker auf Proxmox VE.