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) (KVM-Doku im Linux-Kernel). 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.
LXC: Host-Kernel -> [Userspace A] [Userspace B]
KVM: Hypervisor -> [Kernel A + Userspace A] [Kernel B + Userspace B]
Performance: LXC gegen VM
LXC teilt den Host-Kernel, KVM nutzt Hardware-Beschleunigung. Der konkrete Durchsatz hängt vom Workload, den Treibern und dem Storage ab; pauschale Prozentwerte sind ohne Messung nicht belastbar. Unterschiede bestehen bei I/O, Overhead und 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.
Rechenbeispiel mit angenommenen Werten: 50 Dienste mit jeweils angenommenen 256 MiB Prozessspeicher benötigen zusammen 12,5 GiB. Werden für jede VM zusätzlich 256 MiB für Gastkernel und Basisdienste angesetzt, ergeben sich 25 GiB. Host, Cache und Reserven kommen in beiden Varianten hinzu; reale Werte müssen gemessen werden.
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 (Proxmox-Container-Doku). 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 (LXC-Security-Doku). 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. Für Anwendungscontainer (OCI/Docker) mit hoher Isolation und Live-Migration empfiehlt die Proxmox-Dokumentation die Ausführung innerhalb einer QEMU-VM.
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
| Kriterium | LXC-Container | KVM-VM |
|---|---|---|
| Kernel | geteilt mit Host | eigener Kernel |
| Betriebssysteme | nur Linux | jedes OS inkl. Windows, BSD |
| Overhead / Dichte | sehr gering, hohe Dichte | höher, weniger Instanzen pro Host |
| Startzeit | Sekundenbruchteile | voller Boot-Vorgang |
| Isolation | schwächer (geteilter Kernel) | stark (Hypervisor-Grenze) |
| Sicherheit untrusted | nur unprivileged, mit Vorsicht | bevorzugt |
| Live-Migration | nein (nur Restart-Migration) | ja, ohne Downtime |
| Snapshots | ja (storageabhängig) | ja (storageabhängig) |
| Eigene Kernel-Module | nein | ja |
| Typische Workloads | Webserver, Proxy, DB, interne Tools | Windows, Appliances, untrusted, HA |
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.
Docker: in LXC oder in einer VM?
Docker betreibt Anwendungscontainer, LXC vollständige Linux-Userspaces. Für Docker mit hoher Isolation und Live-Migration ist eine QEMU-VM der dokumentierte Weg. Docker in LXC teilt weiterhin den Host-Kernel und erfordert die Prüfung der Verschachtelung und Berechtigungen. Die Unterschiede zu OCI-Images direkt in Proxmox erklärt Proxmox vs Docker.
Versionen und aktueller Stand
Seit Proxmox VE 9.1 lassen sich Container auch aus OCI-Images erstellen. Anwendungscontainer sind in der Proxmox-Dokumentation als Technology Preview beschrieben; die Einordnung steht im Docker-Vergleich.
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 hat im August 2026 das Support-Ende erreicht (Support-Lifecycle, Stand Oktober 2026). Die grundlegende Trennung von LXC und KVM gilt seit vielen Versionen unverändert.
Auslegung für Ihre Workloads
Die Wahl zwischen LXC und KVM legen wir pro Workload fest, gemeinsam mit Storage, Isolation und HA-Konzept: in der Proxmox-Beratung vor dem Aufbau, im Managed Proxmox im laufenden Betrieb. Ein Erstgespräch klärt den Umfang.
Weiterführend: HA · Storage · Kubernetes · GPU-Passthrough · PBS · Sizing.
Den konkreten Ablauf für einen KVM-Gast zeigt Proxmox VM erstellen: Ubuntu, Linux und Windows.
Die Plattformfrage behandelt Proxmox gegen einen eigenen KVM/libvirt-Stack; sie ist vom Gasttyp zu unterscheiden.
