LXC-Container vs. KVM-VMs in Proxmox: Wann nutzen Sie was

Die Antwort zuerst: drei Fragen entscheiden

Stellen Sie sich für jede Workload folgende Fragen:

1. Braucht sie einen eigenen Kernel? Ein anderes Betriebssystem (Windows, BSD), eine bestimmte Kernel-Version, Kernel-Module oder tiefes Kernel-Tuning → VM. Container teilen sich den Kernel des Hosts, ohne Ausnahme.
2. Wie stark muss die Isolation sein? Nicht vertrauenswürdiger Code, Mandantentrennung, Compliance-Grenzen → VM. Die Grenze der Hardware-Virtualisierung ist kategorisch stärker als Namespace-Isolation.
3. Müssen Sie sie verschieben können, ohne sie zu stoppen? Live-Migration zwischen Cluster-Nodes gibt es nur bei VMs; Container werden per Stopp-und-Neustart verschoben.

Lauten alle drei Antworten "nein" (ein vertrauenswürdiger, Linux-basierter, neustartbarer Dienst), gibt Ihnen ein LXC-Container dieselbe Workload in einem Bruchteil des Footprints und bootet dabei in etwa einer Sekunde. Das beschreibt einen Großteil der realen Infrastruktur: Reverse Proxys, DNS, interne Tools, Per-App-Dienstinstanzen. Deshalb ist das praktische Proxmox-Muster gemischt: VMs für die Kronjuwelen und alles Fremde, Container für die Flotte kleiner Linux-Dienste drumherum.

Wie beide tatsächlich funktionieren

Eine KVM-virtuelle Maschine ist ein vollständiger Computer in Software: QEMU stellt virtuelle Hardware bereit, KVM (das Hypervisor-Modul des Kernels) führt Gast-Code mit Hardwarebeschleunigung aus, und der Gast läuft mit seinem eigenen Kernel auf dieser Hardware, von seinem eigenen Disk-Image aus. Der Host sieht einen Prozess; der Gast weiß im Grunde nicht, dass er virtualisiert ist (größtenteils: Die paravirtualisierten VirtIO-Treiber existieren genau deshalb, damit er der Geschwindigkeit zuliebe mitspielt).

Ein LXC-Container ist kein Computer: Er ist eine partitionierte Sicht auf den Kernel des Hosts. Namespaces geben ihm private Prozessbäume, Netzwerk-Stacks und Dateisysteme; cgroups messen seinen CPU- und Speicherverbrauch. Es gibt keinen zweiten Kernel, keine virtuelle Hardware, keinen Bootprozess über das Starten von Init hinaus. Deshalb startet ein Container in einer Sekunde und fügt nahezu keinen Overhead pro Instanz hinzu, und deshalb lebt und stirbt jeder Container auf dem Host mit dem einen Kernel dieses Hosts.

Proxmox behandelt beide gleichwertig: dieselbe GUI, dieselben Storage-Backends, dieselben vzdump/PBS-Backups, denselben Firewall- und Snapshot-Workflow. Die folgenden Unterschiede liegen in der Natur der Technologien, nicht an Beschränkungen von Proxmox.

Dichte und Overhead: die ehrliche Version

Proxmox veröffentlicht keine offizielle Zahl nach dem Muster "X Container pro VM-Äquivalent", und Sie sollten jedem misstrauen, der das tut: Dichte hängt vollständig von der Workload ab. Aber der Mechanismus ist unstrittig und es lohnt sich, ihn zu verstehen:

• Jede VM zahlt eine feste Abgabe: ihren eigenen Kernel und Systemprozesse, plus ihren zugewiesenen Speicher, der vorgehalten wird, egal ob der Gast ihn nutzt oder nicht (Ballooning holt unvollständig etwas davon zurück). Zwanzig kleine VMs bedeuten zwanzig Kernel und zwanzig Speicherreservierungen.
• Zwanzig Container teilen sich einen Kernel und einen Page Cache, und ihre cgroup-Speicherlimits sind Obergrenzen, keine Reservierungen; RAM, den ein Container nicht nutzt, ist einfach freier RAM für den Host.

Bei CPU-gebundener Arbeit ist der Durchsatzunterschied gering: Die hardwaregestützte Ausführung von KVM ist effizient, und eine ausgelastete VM ist fast so schnell wie ein ausgelasteter Container. Der Unterschied zeigt sich bei der Speicherökonomie und dem Overhead pro Instanz: Auf einem Host mit vielen kleinen Diensten vervielfacht das Containerisieren üblicherweise, wie viele davon passen, weniger weil Container "schneller" sind, sondern weil VMs reservieren, was untätige Dienste nie nutzen. Bemessen Sie den Host so oder so nach den Virtualisierungsregeln unseres Sizing-Guide. RAM ist in beiden Modellen die bindende Restriktion.

Isolation: Was "unprivileged" bringt, und was nicht

Proxmox legt Container standardmäßig unprivileged an, und dabei sollten Sie es belassen: Der Root des Containers wird auf eine harmlose, hoch nummerierte UID auf dem Host abgebildet, sodass eine vollständige Kompromittierung des Container-Root den Angreifer in einem unprivileged Host-Konto landen lässt. Kombiniert mit AppArmor, seccomp und cgroups ist ein unprivileged LXC-Container eine respektable Grenze für vertrauenswürdige Workloads.

Trotzdem ist das keine VM-Grenze. Jeder Syscall eines Containers trifft direkt auf den Kernel des Hosts: Die Angriffsfläche zwischen Container und Host ist die gesamte Kernel-Schnittstelle, gegenüber der viel schmaleren Hypervisor-Schnittstelle einer VM. Die praktischen Regeln, die sich daraus ergeben:

• Nicht vertrauenswürdiger oder dem Internet ausgesetzter Code mit hohem Risiko, andere Mandanten, compliance-getrennte Workloads → VM. Dafür ist die stärkere Grenze da.
• Privileged Containers (nicht die Standardeinstellung) schwächen das Ganze erheblich: Behandeln Sie sie als Legacy-Notausgang, nicht als Option. Wenn eine Workload einen privileged Container "braucht", will sie eigentlich meist eine VM.
• Container mit aktiviertem nesting (für den Komfort von Docker und systemd) lockern die Isolation weiter: in Ordnung für vertrauenswürdige interne Dienste, ein weiterer Punkt gegen den Einsatz für alles Zweifelhafte.

Die Docker-Frage

Die meistgestellte Version dieses Vergleichs lautet eigentlich: "Wo kommen meine Docker-Container hin?" Proxmox' eigene aktuelle Empfehlung, über die Jahre abgeschwächt, aber in der Richtung konsistent: Für den Produktivbetrieb (besonders wo Isolation oder Live-Migration wichtig sind) läuft Docker innerhalb einer VM, nicht innerhalb eines LXC-Containers. Docker-in-LXC (mit aktiviertem nesting) ist in Homelabs beliebt, weil es den Overhead einer VM umgeht, aber es stapelt zwei Container-Runtimes auf einem Kernel und hat eine Geschichte von Brüchen bei Host-Upgrades, die Art von Zerbrechlichkeit, die man in einem Lab akzeptiert und im Produktivbetrieb bereut.

Beachtenswert, während es reift: Seit PVE 9.1 kann Proxmox Container direkt aus OCI-Images (dem Docker-Image-Format) als Technology Preview erstellen: ein Image pullen und als von Proxmox verwalteten Anwendungscontainer ausführen, ganz ohne Docker-Daemon. Das ist als künftige native Antwort wirklich vielversprechend, aber "Technology Preview" bedeutet genau das; die langweilige VM bleibt die Empfehlung für den Produktivbetrieb, solange sich das noch nicht gesetzt hat.

Also: eine "Docker-Host"-VM (oder ein paar, nach Vertrauensdomäne), Docker darin, und Proxmox verwaltet die VM: Sie bekommen Isolation auf VM-Niveau, Live-Migration für den gesamten Docker-Bestand und saubere Host-Upgrades.

Was nur VMs können, und worin LXC am besten ist

Über die drei entscheidenden Fragen hinaus die konkrete Liste dessen, was nur VMs können: Windows und andere Nicht-Linux-Gäste, angepasste oder neuere Kernel als der des Hosts, Kernel-Module (WireGuard ist bereits Bestandteil des Kernels, aber zum Beispiel spezialisierte Storage- oder Forschungsmodule), PCIe-Passthrough über VFIO (GPUs für Transcoding oder KI, HBAs für einen NAS-Gast), und, operativ der große Punkt, Live-Migration sowie Hypervisor-unabhängige Portabilität (ein VM-Disk-Image lässt sich auf jeden KVM-Host verschieben; die Konfiguration eines Containers ist stärker mit seinem Host verwoben).

Das ureigene Terrain von LXC entsprechend: das Muster der vielen kleinen Dienste. Ein Container pro Dienst (hier DNS, dort ein Reverse Proxy, ein Postgres für diese App, ein Monitoring-Stack), jeder unabhängig snapshotfähig, gesichert, in den Ressourcen begrenzt und neustartbar, zu Kosten pro Instanz, die niedrig genug sind, dass "ein Dienst, ein Container" sich als Grundsatz leisten lässt. Bind Mounts fügen eine stille Superkraft hinzu: Host-Verzeichnisse direkt in Container einhängen, ganz ohne Netzwerk-Dateisystem, naheliegend für einen Container, der Daten verarbeitet, die auf dem großen ZFS-Pool des Hosts liegen.

Ein Cluster-Vorbehalt, den Sie einplanen sollten: "Migration" von Containern zwischen Nodes ist Migration per Neustart: stoppen, verschieben, starten (Sekunden an Ausfallzeit bei einem leichten Container, aber Ausfallzeit). HA funktioniert genauso: Die Container eines ausgefallenen Nodes starten anderswo neu. Verträgt ein Dienst das nicht, gehört er in eine VM. Genau dafür ist Frage 3 da.

Die Entscheidungstabelle

Häufig gestellte Fragen

Kann ich einen Container später in eine VM umwandeln (oder umgekehrt)?

Eine Konvertierung per Klick gibt es nicht. Der Festplatteninhalt ist kompatibel (es sind durchweg Linux-Dateisysteme), aber die Verpackung unterscheidet sich: Eine VM braucht einen Kernel, einen Bootloader und Init, was ein Container-Image nicht mitbringt. Der praktische Weg ist Neuausrollen und Daten migrieren, was für die kleinen Dienste, die Container hosten, selten schmerzhaft ist. Die Asymmetrie ist beim Deployment eine Überlegung wert: "Als VM starten, später containerisieren" kostet nur Ressourcen, während "als LXC starten, später zur VM machen" eine Migration kostet. Bei echter Unsicherheit ist die VM die halbwegs umkehrbare Wahl.

Wie viel schneller ist LXC wirklich?

Bei reiner Rechenleistung: kaum. KVM führt Gast-CPU-Instruktionen mit Hardwareunterstützung aus, sodass eine rechenintensive VM innerhalb weniger Prozent der nativen Leistung bleibt. Die ehrlichen Unterschiede: Bootzeit (eine Sekunde gegenüber einem vollständigen OS-Boot), Speicherökonomie (Obergrenzen gegenüber Reservierungen: daher kommt die Dichte) und die Länge des I/O-Pfads (Container-I/O ist Host-I/O; VM-I/O läuft über VirtIO, das schnell, aber nicht kostenlos ist). Wenn Ihre Motivation "Performance" ist, messen Sie zuerst; wenn es "30 kleine Dienste auf einer Maschine unterbringen" ist, spricht der Fall für LXC von selbst.

Funktionieren Container mit Proxmox HA und Clustering?

Ja, mit einem Verhaltensunterschied: keine Live-Migration. Einen Container zwischen Nodes zu verschieben (für Wartung oder durch HA nach einem Node-Ausfall) läuft über Stoppen-Übertragen-Starten, planen Sie also mit Sekunden bis zu einer Minute Ausfallzeit pro Umzug statt der unmerklichen Umschaltung, die VMs bekommen. Für die meisten Dienste der Container-Klasse ist das kein Problem (und dass HA Ihren DNS-Container auf einem überlebenden Node neu startet, ist besser, als dass er ausfällt); wo das nicht gilt, siehe Frage 3, und nutzen Sie eine VM. Die Cluster-Mechanik behandelt unser HA-Guide.

Sollte mein gesamtes Setup der Einfachheit halber einfach nur aus VMs bestehen?

Das ist eine vertretbare Vereinfachung (ein Modell, überall die stärkste Isolation, Live-Migration für alles), und wenn Sie wenige Dienste und reichlich RAM haben, greifen Sie ruhig zu. Der Preis ist Dichte: Untätige VMs reservieren Arbeitsspeicher, den untätige Container nicht reservieren würden, sodass eine reine VM-Flotte für dieselbe Workload einen größeren Host braucht. Die meisten Betreiber landen bei der in diesem Artikel beschriebenen Mischung, sobald die Zahl der Dienste wächst; für Reinheit in die eine oder andere Richtung gibt es keinen Preis.

Deployment bei Serverside

Beide Modelle wollen dasselbe Fundament: Cores, RAM und schnelles NVMe. Unsere Proxmox Dedicated Server kommen vorinstalliert und in unter einer Minute provisioniert auf ASN 55285, mit genug RAM-Optionen, um die reine VM-Flotte zu betreiben, falls das Ihr Stil ist, privater Vernetzung für Multi-Node-Setups und KVM-over-IP für den Host selbst. Bemessen Sie die Maschine mit dem Sizing-Guide für Server (summieren Sie Ihre Gäste, RAM ist die Restriktion), und bauen Sie dann mit dem Rest der Serie weiter: Ersteinrichtung, Netzwerk und Backups.