Die Entscheidung ist selten so klar wie in Vergleichstabellen
Die meisten Proxmox-Einsteiger fragen "LXC oder VM?", als gäbe es eine Universalregel. Gibt es nicht. Die ehrliche Faustregel: Wenn der Dienst auch nativ unter Linux läuft und keine eigene Kernel-Version braucht, ist LXC fast immer die bessere Wahl. Sobald Kernel-Module, ein anderes Betriebssystem oder harte Isolation gebraucht werden, führt an KVM kein Weg vorbei.
LXC vs VM – Vergleich
| Kriterium | LXC Container | KVM VM |
|---|---|---|
| Isolation | Kernel-Sharing | Vollständig |
| Performance | Near-Native | ~2–5% Overhead |
| RAM-Overhead | ~50–100 MB | ~200–500 MB |
| Boot-Zeit | Sekunden | 10–30 Sek. |
| Windows | Nein | Ja |
| Live-Migration | Nein | Ja |
Wann LXC, wann VM?
LXC: Webserver, Datenbanken, DNS/DHCP (PiHole), Grafana, Nextcloud, Home Assistant – alles, was einen Linux-Kernel-Systemaufruf braucht, aber keinen eigenen Kernel.
VM: Windows Server, Docker-Host (dazu unten mehr), pfSense/OPNsense (braucht eigenen Netzwerk-Stack im Kernel), Test-Umgebungen mit abweichender Kernel-Version.
LXC Container erstellen
pveam update
pveam download local ubuntu-24.04-standard_24.04-2_amd64.tar.zst
pct create 200 local:vztmpl/ubuntu-24.04-standard_24.04-2_amd64.tar.zst \
--hostname web-lxc --memory 1024 --swap 512 --cores 2 \
--storage local-lvm --rootfs local-lvm:8 \
--net0 name=eth0,bridge=vmbr0,ip=192.168.1.200/24,gw=192.168.1.1 \
--password PASSWORT --start 1
pct status 200
pct enter 200
Privileged vs. Unprivileged – der Punkt, an dem die meisten stolpern
Standardmäßig erstellt Proxmox unprivileged Container – Root im Container ist NICHT Root auf dem Host, sondern auf eine hohe UID gemappt. Das ist sicherheitstechnisch richtig und sollte der Normalfall bleiben. Das Problem: Manche Dienste, die tief ins System eingreifen (Docker, manche VPN-Tools, Bind-Mounts von Host-Devices), brauchen mehr Rechte, als ein unprivileged Container hat.
Bevor man deswegen auf privileged umschaltet – meistens reicht es, gezielt einzelne Capabilities freizugeben (features: nesting=1,keyctl=1), statt den kompletten Container privileged zu machen und damit die Isolation faktisch aufzugeben.
Docker in LXC – geht, mit Einschränkungen
pct create 202 local:vztmpl/ubuntu-24.04-standard_24.04-2_amd64.tar.zst \
--unprivileged 0 \
--features keyctl=1,nesting=1 \
--hostname docker-lxc
pct enter 202
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
Wichtig: nesting=1 und keyctl=1 reichen für die meisten Docker-Anwendungsfälle, aber nicht für alle Container-Images – manche brauchen Kernel-Module (z.B. WireGuard-Images, die wireguard.ko laden wollen), die im LXC-Kontext grundsätzlich nicht funktionieren, weil der Kernel mit dem Host geteilt wird. Wer viele verschiedene Docker-Workloads fährt oder unsicher ist, was die Images brauchen, sollte direkt eine kleine VM als Docker-Host nehmen – der Ärger mit halb-funktionierenden LXC-Docker-Setups ist es meist nicht wert.
Was Vergleichstabellen gerne verschweigen
LXC-Container lassen sich nicht live migrieren – nur im gestoppten Zustand. Wer also unterbrechungsfreie Migrationen zwischen Nodes für HA-Zwecke braucht, ist mit KVM-VMs im Vorteil, selbst wenn LXC für den reinen Workload eigentlich die bessere Wahl wäre.
Fazit
LXC spart Ressourcen und startet in Sekunden – ist aber kein Ersatz für vollständige Isolation. Die Entscheidung hängt weniger vom Workload allein ab als davon, ob Live-Migration, Kernel-Module oder ein fremdes Betriebssystem gebraucht werden.
Proxmox-Virtualisierung für Unternehmen in Heidelberg, Mannheim und der Rhein-Neckar-Region. Jetzt anfragen.