VM, LXC oder Docker auf Proxmox? Der Entscheidungs-Guide — Enterprise Homelab #5

Im vierten Teil dieser Serie haben wir unser TrueNAS in die Active-Directory-Domäne gehängt und ein zweites NAS per Rsync abgesichert. Damit steht der Storage. Jetzt kommt die Frage, an der sich in jedem Homelab die Geister scheiden: VM, LXC oder Docker — was nimmst du wann? Auf Proxmox triffst du diese Entscheidung bei jedem neuen Dienst, und die meisten wählen aus dem Bauch heraus. Diese Folge räumt damit auf.

Das Video dazu — schau es dir gerne zuerst an, dann macht dieser Guide noch mehr Sinn:

Drei Welten, ein Hypervisor

VM, LXC und Docker lösen alle dasselbe Grundproblem — Dienste sauber voneinander trennen — aber auf völlig unterschiedlichen Ebenen. Wer den Unterschied verstanden hat, wählt nie wieder falsch. Die kurze Version:

• Virtuelle Maschine (VM): ein komplettes Betriebssystem mit eigenem Kernel, vom Hypervisor hardwareseitig isoliert.
• LXC-Container: ein Linux-System, das sich den Kernel des Hosts teilt — leichtgewichtig, aber näher am Host.
• Docker: kein Betriebssystem, sondern einzelne Anwendungen als portable Container, definiert in Code.

Schritt 1: Virtuelle Maschinen — maximale Isolation

Eine VM bekommt vom Proxmox-Hypervisor (KVM) virtuelle Hardware und bootet ihren eigenen Kernel. Damit läuft in der VM ein vollständig getrenntes Betriebssystem — egal ob Linux, Windows oder BSD. Die Trennung zwischen Gast und Host ist eine echte Hypervisor-Grenze: Was in der VM passiert, bleibt in der VM.

Dieser Komfort kostet etwas Overhead — in der Praxis aber weniger, als viele denken:

• CPU-Overhead: moderne KVM-Virtualisierung liegt bei nur ~1–3 %.
• RAM-Overhead: pro VM rechnet man mit etwa 256–512 MB extra für das Gast-OS.

Der große Trumpf der VM ist die Live-Migration: In einem Cluster verschiebst du eine laufende VM von Node A auf Node B — ohne Downtime, während der Dienst weiterläuft. Genau das macht VMs zur ersten Wahl, wenn Ausfallsicherheit zählt.

Faustregel: Sobald ein Dienst ein anderes OS braucht, harte Isolation verlangt oder live-migrierbar sein soll — VM.

Schritt 2: LXC-Container — leichtgewichtig und schnell

Ein LXC-Container ist ein vollwertiges Linux-System, das sich aber den Kernel des Proxmox-Hosts teilt (Shared Kernel) statt einen eigenen zu starten. Der Unterschied zur VM ist fundamental: kein zweiter Kernel, kein virtuelles BIOS, kein Boot-Vorgang eines kompletten OS.

Das Ergebnis ist beeindruckend effizient:

• Boot in 1–3 Sekunden statt einer halben Minute.
• ~0 % CPU-Overhead — der Container nutzt den Host-Kernel direkt.
• RAM-Verbrauch ist nur der tatsächlich genutzte Speicher, keine fix reservierte Zuteilung.

Der Preis dafür ist die geringere Isolation — und hier wird es sicherheitsrelevant. LXC kennt zwei Betriebsarten:

• Privilegiert: UID 0 im Container ist UID 0 (root) auf dem Host. Bricht jemand aus, hat er Root-Rechte auf dem Proxmox-Host. Nur für vertrauenswürdige Workloads.
• Unprivilegiert (Standard & empfohlen): per UID-Mapping wird root im Container auf eine harmlose, unprivilegierte UID auf dem Host abgebildet. Ein Ausbruch landet im Nichts.

Wichtig: LXC-Container immer unprivilegiert betreiben, außer du hast einen sehr guten Grund dagegen. Das ist die wichtigste Sicherheitsentscheidung bei Containern auf Proxmox.

Schritt 3: Docker — Anwendungen als Code

Docker spielt in einer anderen Liga: Hier geht es nicht um ein Betriebssystem, sondern um einzelne Anwendungen. Ein Docker-Container bündelt App plus alle Abhängigkeiten in ein portables Image, das überall identisch läuft. Der eigentliche Charme liegt in Docker Compose: Ein kompletter Stack — App, Datenbank und Netzwerk — wird in einer einzigen YAML-Datei beschrieben und mit einem Befehl hochgezogen.

Damit wird Infrastruktur zu versionierbarem Code: Stack löschen, YAML anpassen, neu starten — reproduzierbar und sauber. Die Grundbefehle zur Kontrolle:

sudo docker ps
sudo docker --version

Eine entscheidende Frage stellt sich aber: Wo läuft Docker? Auf einem LXC-Container? Direkt auf dem Host? Die Antwort aus der Praxis ist klar.

Goldstandard: Docker immer auf einer VM betreiben — nicht im LXC, nicht auf dem blanken Host. So bleibt der Docker-Host sauber isoliert, beliebig skalierbar und über die VM live-migrierbar. Du bekommst das Beste aus beiden Welten: die harte Trennung der VM und die Flexibilität von Docker.

Der direkte Vergleich

Kriterium	VM	LXC	Docker
Kernel	Eigener Kernel	Host-Kernel (shared)	Host-Kernel (App-Ebene)
Isolation	Sehr hoch (Hypervisor)	Mittel (UID-Mapping)	App-Ebene
CPU-Overhead	~1–3 %	~0 %	~0 %
RAM	256–512 MB extra/VM	nur genutzt	nur genutzt
Boot	Sekunden bis Minute	1–3 Sekunden	Millisekunden
Live-Migration	Ja, ohne Downtime	Eingeschränkt	Über die VM
Ideal für	Anderes OS, harte Trennung, HA	Leichte Linux-Dienste	App-Stacks (Compose)

Schritt 4: Live-Demo — alle drei auf Proxmox einrichten

Theorie ist gut, sehen ist besser. Im Video richten wir alle drei direkt auf dem Proxmox-Host ein: eine VM aus einem ISO/Cloud-Image, einen unprivilegierten LXC-Container aus einem Template, und einen Docker-Host als VM, auf dem wir einen ersten Compose-Stack starten. So siehst du den Unterschied in Boot-Zeit, Ressourcenverbrauch und Handling nicht nur in der Theorie, sondern im echten Betrieb.

Für die Docker-Verwaltung zeige ich außerdem dockhand — einen Docker-Stack-Manager, mit dem sich Container komfortabel steuern lassen.

Schritt 5: Der Entscheidungsbaum — 5 Fragen zur richtigen Wahl

Am Ende braucht es keine Bauchentscheidung mehr, sondern eine klare Logik. Geh die Fragen der Reihe nach durch — die erste, die mit „Ja“ beantwortet wird, gibt die Antwort:

1. Brauchst du ein anderes Betriebssystem (Windows, BSD) oder einen eigenen Kernel? → VM
2. Brauchst du harte Isolation oder Live-Migration ohne Downtime? → VM
3. Ist es ein leichter Linux-Dienst, der schnell und ressourcenschonend laufen soll? → LXC (unprivilegiert)
4. Ist es eine App bzw. ein App-Stack, der portabel und reproduzierbar sein soll? → Docker (auf einer VM)
5. Im Zweifel und es soll skalierbar + sicher bleiben? → Docker auf einer VM als Goldstandard

Fazit & nächste Schritte

Damit ist die ewige Frage geklärt — und zwar nach Use-Case, nicht nach Bauchgefühl:

• ✅ VM — eigener Kernel, maximale Isolation, Live-Migration ohne Downtime
• ✅ LXC — leichtgewichtig, Boot in Sekunden, ~0 % Overhead — immer unprivilegiert
• ✅ Docker — Apps als Code via Compose, am besten auf einer VM
• ✅ Goldstandard — Docker auf einer VM: sicher, skalierbar, migrierbar
• ✅ Entscheidungsbaum — 5 Fragen, klare Antwort für jeden Dienst

Im nächsten Video geht es ans Netzwerk: Wir setzen eine OPNsense-Firewall als VM auf und trennen unser Homelab sauber in Netzsegmente — das Fundament für ein wirklich sicheres Setup.

Welche der drei nutzt du am meisten — und wofür? Schreib es in die Kommentare. Wenn dir der Guide weitergeholfen hat, freue ich mich über ein Abo — die Serie wächst Folge für Folge weiter. 👍