LXC vs KVM in Proxmox: Container oder VM?

In Proxmox VE haben Sie zwei Wege, Workloads zu virtualisieren: LXC-Container und KVM-VMs. Der entscheidende Unterschied ist der Kernel. Ein LXC-Container teilt sich den Linux-Kernel des Proxmox-Hosts, ist dadurch sehr leichtgewichtig, startet in Sekunden und verbraucht wenig RAM, läuft aber ausschließlich unter Linux. Eine KVM-VM virtualisiert vollständige Hardware und bringt einen eigenen Kernel mit, kann also jedes Betriebssystem inklusive Windows ausführen und ist stärker vom Host isoliert, zum Preis von etwas mehr Overhead. Beide Typen verwalten Sie in derselben Proxmox-Oberfläche. Die Faustregel: LXC für viele kleine Linux-Dienste, KVM für Windows, fremde Kernel, hohe Isolation und Live-Migration.

Dieser Artikel gehört zu unserem Proxmox-Wissensbereich. Was Proxmox selbst ist, erklären wir unter Was ist Proxmox. Wenn Sie LXC mit Docker vergleichen, hilft Proxmox vs Docker.

Der grundlegende Unterschied: geteilter Kernel vs eigener Kernel

Die Architektur erklärt fast alle weiteren Unterschiede.

LXC (Linux Containers) ist Betriebssystem-Virtualisierung. Der Container ist im Kern ein isolierter Userspace auf dem Host-Kernel. Trennung entsteht über Linux-Namespaces (Prozesse, Netzwerk, Dateisystem, Nutzer) und cgroups (Ressourcenlimits). Es gibt keinen zweiten Kernel, keine emulierte Hardware und keinen Boot-Vorgang im klassischen Sinne. Das macht Container schlank, schnell und speicherschonend, bindet sie aber an den Kernel und die Architektur des Hosts.

KVM (Kernel-based Virtual Machine) ist Hardware-Virtualisierung. QEMU stellt virtuelle Hardware bereit, KVM beschleunigt das über die Virtualisierungsfunktionen der CPU (Intel VT-x, AMD-V). Die VM bootet ein vollständiges Betriebssystem mit eigenem Kernel, eigenen Treibern und eigenem Speicherbereich. Der Gast weiß im Idealfall nicht, dass er virtualisiert läuft, und ist vom Host durch die Hypervisor-Grenze getrennt.

Performance und Ressourcen

Bei reiner CPU-Last liegen beide Technologien nah an Bare Metal: LXC erreicht praktisch native Geschwindigkeit, KVM dank Hardware-Beschleunigung typischerweise rund 97 bis 99 Prozent. Der eigentliche Unterschied liegt im Overhead und in der Dichte:

• RAM: Ein LXC-Container belegt nur den Speicher der laufenden Prozesse. Eine VM reserviert zusätzlich Speicher für ihren eigenen Kernel und die emulierte Hardware. Auf demselben Host laufen daher deutlich mehr Container als VMs.
• Startzeit: Container starten in Sekundenbruchteilen, weil kein Kernel gebootet wird. Eine VM durchläuft einen vollständigen Boot-Vorgang.
• Speicher- und I/O-Overhead: Container greifen über den Host-Kernel direkt auf das Dateisystem zu. VMs nutzen virtuelle Disks und virtuelle Treiber (VirtIO), was minimal mehr Overhead erzeugt.

Praktisch heißt das: Wer 50 kleine Linux-Dienste betreiben will, fährt mit Containern dichter und sparsamer. Wer wenige, große oder gemischte Workloads betreibt, profitiert oft mehr von der Flexibilität der VM.

Betriebssysteme: Windows nur in KVM

Das ist der härteste Entscheidungsfaktor. Weil LXC den Linux-Kernel des Hosts mitbenutzt, laufen darin ausschließlich Linux-Distributionen (Debian, Ubuntu, Rocky, Alpine und so weiter). Windows, Windows Server, BSD-Systeme oder Appliances mit eigenem Kernel laufen in Proxmox nur als KVM-VM. Auch wenn Sie spezielle Kernel-Module, einen anderen Kernel-Zweig oder ein Echtzeit-Kernel brauchen, führt kein Weg an einer VM vorbei. Container teilen sich immer genau den Kernel, den der Proxmox-Host fährt.

Isolation und Sicherheit: privileged vs unprivileged LXC

Hier liegt der wichtigste Sicherheitsunterschied. Eine KVM-VM ist durch die Hypervisor-Grenze stark isoliert: Ein Ausbruch auf den Host erfordert eine Schwachstelle im Hypervisor selbst, was bei KVM sehr selten ist. Ein kompromittierter Gast-Kernel bleibt im Gast.

Ein LXC-Container teilt den Host-Kernel. Eine Kernel-Schwachstelle ist damit potenziell ein Einfallstor für alle Container und den Host. Proxmox entschärft das über zwei Container-Modi:

• Unprivileged Container (Standard und empfohlen): Alle UIDs und GIDs werden in einen anderen Bereich gemappt. Root im Container (UID 0) wird auf eine unprivilegierte UID auf dem Host abgebildet, üblicherweise 100000. Ein erfolgreicher Ausbruch träfe damit nur einen rechtearmen Host-Nutzer, nicht root. Zusätzlich greifen AppArmor-Profile, seccomp-Filter und Namespaces.
• Privileged Container: Root im Container ist auch root auf dem Host. Bricht ein Prozess durch eine Kernel-Lücke, einen falsch gesetzten Mount oder einen LXC-Bug aus, läuft er mit Root-Rechten auf dem Proxmox-Host. Das LXC-Projekt behandelt Ausbrüche aus privileged Containern ausdrücklich nicht als CVE-würdige Sicherheitslücken. Privileged Container gehören deshalb nur in vertrauenswürdige Umgebungen, etwa wenn ein Container zwingend NFS- oder CIFS-Mounts braucht.

Für untrusted oder mandantengetrennte Workloads ist die VM die robustere Wahl. Wer maximale Isolation und gleichzeitig Container will, kann LXC auch innerhalb einer KVM-VM verschachteln, das empfiehlt auch die Proxmox-Dokumentation.

Live-Migration, Snapshots und Backup

Ein Unterschied, der im Cluster-Betrieb schnell wichtig wird:

• Live-Migration: Proxmox unterstützt echte Live-Migration ohne Downtime nur für KVM-VMs. Laufende VMs verschieben Sie unterbrechungsfrei zwischen Nodes, etwa für Wartung oder Updates. LXC-Container kennen keine Live-Migration. Sie werden per Restart-Migration verschoben: kurz stoppen, auf den Zielknoten umziehen, dort starten. Das bedeutet eine kurze, planbare Downtime. Bei geteiltem oder repliziertem Storage geht das sehr schnell.
• Snapshots: Beide Typen unterstützen Snapshots, sofern der Storage es kann. Auf ZFS, Ceph oder LVM-thin lassen sich Container und VMs einfrieren und zurückrollen. Auf einfachem Verzeichnis-Storage ohne Snapshot-Fähigkeit ist das eingeschränkt.
• Backup: Beide Typen sichern Sie mit vzdump beziehungsweise dem Proxmox Backup Server, dedupliziert, inkrementell und verschlüsselt. Inhalte von Bind-Mounts werden bei Containern allerdings nicht mitgesichert.

Wenn Hochverfügbarkeit mit unterbrechungsfreier Wartung das Ziel ist, sprechen diese Punkte klar für KVM.

Entscheidungstabelle: Wann LXC, wann KVM

Kurzform: Standardmäßig LXC für leichtgewichtige Linux-Dienste, KVM immer dann, wenn eines dieser Kriterien zutrifft: Windows oder Nicht-Linux, eigener Kernel, hohe Isolationsanforderung, oder Live-Migration ohne Downtime.

Versionen und aktueller Stand

Die Aussagen beziehen sich auf aktuelle Proxmox-Versionen. Proxmox VE 9.2 (veröffentlicht im Mai 2026, auf Basis von Debian 13) ist die aktuelle Generation, Proxmox VE 8 wird noch bis zum 31. August 2026 unterstützt. Die grundlegende Trennung von LXC und KVM gilt seit vielen Versionen unverändert.

Betrieb und Unterstützung

Ob LXC oder KVM ist selten eine reine Geschmacksfrage, sondern hängt an Sicherheitsanforderungen, Betriebssystem, Dichte und Verfügbarkeit. Wir betreiben Proxmox produktiv für Kunden und entscheiden diese Frage pro Workload sauber durch, inklusive Storage-Wahl, Isolation und HA-Konzept. Wenn Sie eine fundierte Auslegung oder den laufenden Betrieb möchten, sehen Sie sich unsere Leistungen zu Proxmox und Private Cloud an oder buchen Sie direkt ein unverbindliches Kennenlernen.