Proxmox: Wann LXC-Container statt VMs sinnvoll sind – Praxis-Vergleich
"Warum zur Hölle braucht meine WordPress-Instanz einen ganzen Linux-Kernel?" – diese Frage trieb mich 2018 zum ersten Mal zu LXC-Containern. Zehn CPU-Kerne, 16GB RAM und eine 20GB Disk nur für eine simple Webapp? Bei diesen Ressourcen-Preisen können wir uns diese Verschwendung nicht mehr leisten. Aber VMs sind nicht grundsätzlich schlecht – sie haben nach wie vor ihr Berechtigungs-Dasein. Lassen Sie uns die Fakten in Ihrem Proxmox-Cluster konkret vergleichen.
1. Ressourcen-Neid: So unterschiedlich teilen sich LXC und KVM die Hardware
LXC-Container sind keine magischen Ressourcen-Sparer – sie nutzen einfach effizienter.
Beispiel 1: Memory Overhead
# KVM VM mit 4GB RAM (idle)
$ free -h
total used free shared buff/cache available
Mem: 3.9G 300M 3.3G 10M 300M 3.4G
# LXC mit 4GB RAM (idle)
$ free -h
total used free shared buff/cache available
Mem: 62G 1.2G 58G 45M 2.1G 60G (Host hat 64GB)
Meine Messungen zeigen: Eine frische Ubuntu VM belegt 300MB RAM selbst im Leerlauf – der LXC-Container teilt sich den Host-Kernel und schluckt nur das, was die App wirklich braucht. Bei 20, 50 oder 100 Systemen wird dieser Unterschied existenzbedrohend.
Meine Einschätzung: Für Webapps, Datenbanken (nicht alle!) und stateless Services würde ich heute immer erst LXC prüfen. Einzige Ausnahme: Sicherheitskritische Isolation – aber dazu gleich mehr.
2. Storage-Performance: Die unterschätzte Bremse
LXC-NFS-Mounts sind keine gute Idee – aber für lokale SSDs ein enormer Boost.
Beispiel 2: FIO-Benchmark auf NVMe
# KVM mit VirtIO-SCSI (directsync)
$ fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test
--filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
read: IOPS=78.3k, BW=306MiB/s
# LXC mit bind-mount (same hardware)
read: IOPS=152k, BW=594MiB/s
Bind-Mounts im Container erreichen nahezu native Performance – kein SCSI-Stack, kein VirtIO-Overhead. Aber Vorsicht: Diese Messung ist ohne Kernel-Queuing! In der Praxis reicht meist auch der KVM-Wert – außer bei hochfrequenten DB-Transaktionen.
Meine Einschätzung: Für IO-intensive Lasten wie MongoDB oder TimescaleDB bevorzuge ich LXC – wenn die Sicherheit passt. KVM zeigt hier immerhin bessere Isolation gegen Noisy Neighbors.
3. Sicherheit: Wo LXC gefährlich wird
Proxmox wirbt mit „LXC als Lightweight-VMs“ – ein gefährlicher Mythos.
Beispiel 3: Kernel-Exploit in nicht gehardetem Container
// Dirty Pipe (CVE-2022-0847) Ausnutzung
int main() {
int f = open("/etc/passwd", O_RDONLY);
splice(f, 0, pipefd[1], NULL, 1, 0);
write(pipefd[1], "pwned:x:0:0:root:/root:/bin/bash\n", 43);
splice(pipefd[0], 0, f, 0, 1, 0);
}
Ein erfolgreicher Kernel-Exploit im LXC-Container kompromittiert den ganzen Host. KVM hätte den Angriff auf die VM begrenzt. Proxmox‘ Lösung: feature: nesting=0 und AppArmor-Profile.
Meine Einschätzung: Multi-Tenant-Umgebungen mit untrusted Workloads gehören in VMs. Punkt. Für interne Microservices finde ich LXC mit richtigen Security-Einstellungen (unprivileged!) akzeptabel.
Häufige Fehler und wie Sie sie vermeiden
-
Bind-Mount ohne No-Suid:
/dev/shmals Host-Verzeichnis eingebunden? Ohnenosuid,nodev-Flags ist das ein Einfallstor - Überschätzte Unprivileged-Container: Nicht alle Apps laufen unter UID-Mapping (z.B. PostgreSQL mit bestimmten Plugins)
- Snapshot-Illusion: LXC-Snapshots sind nicht crash-consistent – für DBs besser ZFS-Datasets
Fazit und nächster Schritt: Machen Sie den 2-Minuten-Check
- Braucht die App direkten Hardware-Zugriff (GPUs, USB)? → KVM
- Läuft sie als root oder manipuliert Kernel-Strukturen? → KVM
- Reicht Filesystem-Isolation (chroot on steroids)? → LXC
Konkrete Empfehlung: Testen Sie Ihren nächsten Stateless-Service in einem unprivileged LXC mit:
pct create 999 --ostemplate local:vztmpl/ubuntu-22.04-standard.tar.zst \
--unprivileged 1 --mp0 local-lvm:8,mp=/var/lib/mysql
Der (sichere!) Mittelweg existiert – wir müssen ihn nur nehmen.
