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/shm als Host-Verzeichnis eingebunden? Ohne nosuid,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

1. Braucht die App direkten Hardware-Zugriff (GPUs, USB)? → KVM
2. Läuft sie als root oder manipuliert Kernel-Strukturen? → KVM
3. 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.