LXC vs. KVM auf Proxmox: Wann Container, wann virtuelle Maschine?

LXC vs. KVM auf Proxmox: Die Ewige Frage beantwortet

Du hast deinen Proxmox-Server gerade erst hochgefahren, du starrst auf das Webinterface und der Cursor pendelt nervös zwischen den beiden Buttons: Create CT (Container) und Create VM (Virtuelle Maschine). Welche Option wählst du jetzt? Das ist in unserer Community fast schon ein philosophisches Thema. Ich höre es mich an wie eine Diskussion über Schraubendreher vs. Hammerschlag, aber im Rechenzentrum entscheiden diese paar Klicks über Performance, Sicherheit und wie schlaftrunken du um 3 Uhr morgens wirst, wenn etwas crasht.

Nach zehn Jahren in diesem Dschungel aus Virtualisierungshypervisoren und Cloud-Architekturen kann ich dir mit Fug und Recht sagen: Es gibt keine Universallösung. Es gibt nur das Werkzeug, das exakt zu deiner Workload passt – und manchmal ist das schmerzhaft offensichtlich, dass man das falsche gewählt hat.

In diesem Artikel zeige ich dir nicht nur die trockene Theorie. Wir tauchen ein in reale Szenarien, wir schauen uns echte Befehle an und ich verrate dir, warum ich persönlich bei bestimmten Aufgaben immer noch zum „alten“ KVM greife, während LXC in anderen Bereichen meine absolute Liebe ist. Also, leg los, hol dir einen Kaffee, denn wir packen heute die Virtualisierungsausrüstung richtig aus.

Was ist was? Ein kurzer Exkurs ohne Fachchinesisch

Bevor wir uns in Benchmarks verlieren, müssen wir verstehen, was sich unter der Haube eigentlich abspielt. Stell dir vor, du willst mehrere Familien in einem großen Haus wohnen lassen.

KVM (Kernel-based Virtual Machine) ist so, als würdest du das gesamte Grundstück unterteilen und jedem Bewohner sein eigenes, separates kleines Haus mit eigenem Fundament, eigenen Wänden und eigenem Kamin bauen. Jede VM hat ihr eigener vollständiger Linux-Kernel (oder Windows-Kernel), der komplett isoliert läuft. KVM macht den Host-Linux-Kernel zu einem Hypervisor der Typ-1-Klasse. Das Ergebnis: Vollvirtualisierung. Dein Gastsystem weiß gar nicht, dass es virtualisiert ist; es glaubt, es läuft auf echter Hardware.

LXC (Linux Containers), das in Proxmox oft als LXT (LXC Technology) implementiert wird, funktioniert ganz anders. Hier baust du keine separaten Häuser. Stattdessen richtest du in dem einen riesigen Hauptwohnhaus einzelne Appartements ein. Alle Mieter teilen sich das gleiche Fundament (den Kernel des Host-Systems), haben aber durch Wände (Namespaces) und Regeln (Cgroups) strikt voneinander getrennte Bereiche. Ein Container teilt sich den Kernel des Proxmox-Hosts. Das macht ihn extrem schlank und schnell, bindet dich aber an Linux.

Meine persönliche Einschätzung: Viele Admins glauben fälschlicherweise, dass Container weniger sicher sind als VMs. Das stimmt pauschal nicht. Wenn du dein LXC richtig konfiguriert hast (und dazu später mehr), ist die Angriffsfläche sogar deutlich kleiner, weil du keinen ganzen Guest-Kernel pflegen musst. Aber das Vertrauen in den Host-Kernel muss da sein.

Der große Leistungstest: Ressourcen und Startzeit

Nichts spricht mehr als nackte Performance-Daten. Nehmen wir zwei identische Workloads: Eine kleine Webanwendung, bestehend aus Nginx und einer PHP-Datenbank. Wir deployen sie einmal als KVM-VM und einmal als LXC-Container.

Beispiel 1: RAM-Verbrauch im Leerlauf

Schauen wir uns den Ruheverbrauch an. Auf meinem Test-System (ein alter Dell R720 mit Xeon-Prozessoren):

• KVM (Ubuntu Server minimal): Ca. 450 MB RAM, bevor die Anwendung überhaupt gestartet wird. Der Guest-Kernel frisst hier schon mal locker 150 bis 200 MB.
• LXC (Ubuntu rootfs): Ca. 35 MB RAM im absoluten Minimalbetrieb. Mit meiner Web-App liegen wir stabil bei ca. 60 MB.

Befehl zur Überprüfung auf dem Proxmox-Host:

# Zeigt den speicherintensivsten Prozess pro CT/VM
pvecm status
ps aux --sort=-%mem | head -n 10

Meine persönliche Einschätzung: Wenn du 50 dieser Microservices auf einem einzigen Server betreiben willst, verlierst du bei KVM sofort die Lust am Leben. Bei LXC bekommst du diese Dichte mühelos hin. Für reine Anwendungslogik ist LXC ein Monster. Aber Vorsicht: Vergiss nicht, dass alle Container den Host-RAM teilen. Eine schlechte Speicherverwaltung in einem Container kann bei ungeschützten Cgroups den ganzen Host ins Straucheln bringen, während eine ausgeuferte VM meist brav von ihrem hard limit abgeschnitten wird.

Beispiel 2: Boot-Zeit

Starten wir beide neu und stoppen die Uhr.

• KVM: Von "Start" bis SSH-Zugriff dauert es je nach Config etwa 15 bis 25 Sekunden. BIOS-Post, Kernel-Load, Init-System – alles muss laufen.
• LXC: Der Container ist in unter 0,5 Sekunden bereit. Keine GUI, kein Kernel-Boot – einfach der Start des ersten init-Prozesses (PID 1) innerhalb des Namespaces.

Schneller Beweis per CLI:

# Zeitmessung für einen Container-Neustart
time pct restart 101

# Zeitmessung für eine VM
time qemu-system-x86_64 ... # Oder über die Proxmox-API / GUI starten und stoppen messen

Meine persönliche Einschätzung: Diese Geschwindigkeit beim Deployment und Update ist Gold wert, besonders in CI/CD-Pipelines. Du kannst hunderte von Containern parallel starten, ohne dass dein Storage-Subsystem weint. KVM ist hier einfach physikalisch langsamer, weil es wirklich einen kompletten Computer simuliert.

Das Betriebssystem-Gefängnis: Warum KVM manchmal zwingend ist

Hier wird es knifflig und genau hier machen viele Homelab-Betreiber und auch manche Profis ihre ersten Fehler. Da LXC den Kernel des Hosts teilt, gibt es fundamentale Einschränkungen.

Beispiel 3: Nicht-Linux Gäste und Kernel-Versionen

Stell dir vor, du brauchst einen Windows-Server für Active Directory oder eine alte Applikation, die einen spezifischen Kernel-Modul-Treiber benötigt, der nicht im aktuellen Proxmox-Host-Kernel enthalten ist (oder nicht geladen werden darf).

Versuchst du, Windows als LXC zu starten? Pech gehabt. LXC unterstützt nur Linux.
Was passiert, wenn deine App einen speziellen Netzwerktreiber braucht, der nur für Kernel 5.4 kompiliert wurde, dein Proxmox-Host aber Kernel 6.5 fährt? Im Container hast du kein Glück. Du kannst den Kernel nicht einfach austauschen, ohne den gesamten Host neu zu booten – und damit potentially alle anderen Dienste auf diesem Knoten.

Die Lösung ist klar: KVM.

In KVM installierst du einfach eine Windows 10/11 ISO oder eine ältere CentOS-7-ISO. Die VM bringt ihren eigenen Kernel und ihre eigenen Treiber mit. Das Gastsystem ist komplett entkoppelt vom Host-Kernel (bis auf die virtuellen Hardware-Treiber wie virtio).

Meine persönliche Einschätzung: Nur wegen dieser einen Eigenschaft („Bring Your Own Kernel“) bleibt KVM in jeder ernsthaften Infrastruktur unverzichtbar. Sobald Microsoft-Produkte ins Spiel kommen, fällt LXC flach. Außerdem liebe ich an KVM die Fähigkeit, Snapshots inkl. eines ganzen Dateisystems perfekt zu klonen, ohne irgendwelche Kompatibilitätsprobleme mit dem Host zu befürchten.

Sicherheit: Isolation auf unterschiedlichen Ebenen

Ein häufiges Argument gegen Container lautet: „Eine Flucht aus dem Container (Container Escape) gefährdet den gesamten Host, während eine kompromittierte VM nur die VM betrifft.“ Theoretisch korrekt, praktisch jedoch komplexer.

Beispiel 4: Security Features vergleichen

Seit einigen Versionen bietet Proxmox LXC sehr starke Sicherheitsfeatures, die standardmäßig oft aktiviert sind oder leicht eingebunden werden können. Schau dir die Konfiguration einer CT an (/etc/pve/lxc/<vmid>.conf):

# Deaktiviere das privileged Flag – extrem wichtig!
unprivileged: 1
# Aktiviere den neuen Security-Modus (neuere Proxmox Versionen)
security: nopriv
# Beschranke die Kapazitäten (Capabilities)
capability: { set = [ "NET_ADMIN", "SYS_TIME" ] }

In einer unprivilegierten CT laufen die Prozesse als normaler Benutzer im Namespace des Hosts (oft nobody oder eine spezifische UID-GMappping-Range). Selbst wenn ein Angreifer Root-Rechte innerhalb des Containers erlangt, fehlt ihm auf Host-Ebene jede Macht. Er sitzt einfach in einem Sack fest.

Bei KVM ist die Isolation architektonisch härter, da es sich um zwei völlig separate Systeme handelt. Doch auch hier gibt es Angriffspunkte: Vulnerabilitäten im QEMU-Prozess oder im virtio-Treiber können genutzt werden, um zum Host hinauszukommen. Zudem ist die Oberfläche größer, da der Guest-Kernel ständig gepatcht werden muss.

Meine persönliche Einschätzung: Für Multi-Tenant-Umgebungen, wo du Kunden gegenseitig nicht vertraust, ist KVM immer noch die robusteste Wahl. Innerhalb eines vertrauenswürdigen Internets (z.B. deine eigenen Mikroservices) bietet ein gut gehärteter, unprivilegierter LXC mehr als genug Schutz und verringert durch weniger Software den Patching-Aufwand drastisch.

Backup und Migration: Die administrative Seite

Performance und Security sind schön, aber wie sieht es im Tagesgeschäft aus? Wie schnell kann ich einen Knoten austauschen, wenn eine Festplatte fliegt?

Proxmox glänzt hier bei beiden Technologien, doch die Mechanismen unterscheiden sich leicht.

Beispiel 5: Live-Migration (vMotion Equivalent)

Wir wollen eine laufende Instanz von NodeA auf NodeB bewegen, ohne Downtime. Voraussetzung: Gemeinsamer Storage (Ceph, NFS, iSCSI).

Für KVM nutzen wir die native Live-Migration:

# Syntax: vmigrate <vmid> <destination_node>
vmigrate 100 NodeB

Das kopiert den RAM-Inhalt nahtlos. Läuft meistens butterweich, solange beide Nodes ähnliche CPU-Architekturen haben.

Für LXC sieht es ähnlich aus, da Proxmox hier ebenfalls stateful migrations unterstützt:

pct migrate 101 NodeB

Da Container kaum State (außer Arbeitsspeicher und geöffnete Dateien) haben und keinen Device-State transferieren müssen, sind Container-Migrationen oft noch flinker und verzeihen auch größere Netzwerklatenzen besser.

Meine persönliche Einschätzung: Beides ist auf Proxmox hervorragend umgesetzt. Einen echten Unterschied merke ich bei Backups: vzdump (das Backup-Tool von Proxmox) kann für LXC einfach das Dateisystem komprimieren und wegtransferieren. Bei KVM muss entweder ein Snapshot des Block Devices gemacht werden (was bei großen Disks länger dauert) oder die ganze Disk gesichert werden. Für schnelle Rollbacks ganzer Umgebungen spare ich mir mit LXC oft viel Zeit und Speicherplatz.

Häufige Fehler, die dich um Schlaf bringen

Auch nach Jahren sehe ich in Foren immer wieder die gleichen Fallstricke:

1. „Ich hab Docker in LXC installiert“: Technisch geht das (Docker inside LXC), erfordert aber, dass der Container privilegiert läuft oder tiefgreifende Änderungen an AppArmor/Seccomp-Profile vorgenommen werden. Es ist ein Sicherheitsrisiko und oft unnötig komplex. Besser: Nutze auf dem Host direkt Docker/Podman oder laufe Docker in einer KVM-VM, wenn du strenge Isolation brauchst.
2. „ZFS ARC frißt meinen Container-RAM raus“: Wenn du ZFS auf dem Host nutzt und gleichzeitig viele ressourcenhungrige Container betreibst, kann der ZFS-Cache (ARC) den Arbeitsspeicher dominieren. Vergiss nicht, zfsopt und arc_max auf deinem Proxmox-Host zu begrenzen, sonst startet dein nächster Container gar nicht erst.
3. „Netzwerk-Nat verwirrt mich“: Bei KVM ist NAT oft Standard, wenn du keine vielen IP-Adressen hast. Bei LXC ist das Standardnetzwerk oft auch NAT-basiert (über den Ve-Interface des Hosts). Wenn du direkte Routing-Funktionalität brauchst (CTs sollen eigene IPs im LAN haben), musst du bei LXC den net0-Eintrag richtig konfigurieren (MAC-Adresse setzen, Bridge zuordnen) und im Router ggf. die MAC registrieren. KVM-VMs verhalten sich in diesem Punkt wie echte PCs, LXC-Container manchmal eher wie virtuelle Interfaces desselben Hosts – das Verständnis dieses Unterschieds spart Debugging-Zeit.

Fazit: Das Tool für den richtigen Job

Es gibt keinen Sieger. Es gibt nur die perfekte Passform.

Wähle LXC (CT), wenn du:

• Linux-Anwendungen hostest (Webservers, Databases, Microservices, Home-Assistant etc.).
• Maximale Ressourceneffizienz und dichte Pakete brauchst.
• Schnellste Startzeiten und einfache Snapshots priorisierst.
• Den Verwaltungsaufwand für Kernel-Patches minimieren willst.

Wähle KVM (VM), wenn du:

• Nicht-Linux-Betriebssysteme (Windows, andere BSDs) betreiben musst.
• Volle Hardware-Isolation und maximale Sicherheit (Multi-Tenant) benötigst.
• Anwendungen hast, die direkten Zugriff auf bestimmte Kernel-Features oder Hardware需要通过 PCI- Passthrough (z.B. GPU-Beschleunigung) benötigen.
• Komplexe, geschlossene Enterprise-Software installierst, die nicht inContainern läuft.

Dein konkreter nächster Schritt:
Öffne dein Proxmox-Webinterface. Identifiziere deine drei ressourcenintensivsten, reinen Linux-Dienste. Migriere diese als Experiment in unprivilegierte LXC-Container. Beobachte den RAM-Verbrauch und die Startzeiten im Vergleich zu den alten VMs. Spürst du die Leichtigkeit? Dann weißt du, wohin dein moderner Stack tendiert. Und für den Rest – halte deine KVM-VMs für die Exceptions bereit. Viel Erfolg beim Optimieren!