VM oder LXC-Container? Die Entscheidung pro Dienst

Die Frage kommt bei jedem neuen Dienst wieder, und die Antwort „Container sind leichtgewichtiger“ hilft nicht weiter. Sie erklärt nicht, warum manche Dienste im Container Ärger machen und andere jahrelang problemlos laufen.

Der Unterschied liegt an einer Stelle: dem Kernel.

Der eine Unterschied, aus dem alles folgt

Eine virtuelle Maschine bekommt einen eigenen Kernel. Sie ist ein vollständiger Rechner, der zufällig keine eigene Hardware hat.

Ein LXC-Container benutzt den Kernel des Wirts. Er ist eine abgeschottete Gruppe von Prozessen mit eigenem Dateisystem, eigenem Netz und eigenen Benutzern – aber ohne eigenen Kernel.

Daraus folgt praktisch alles Weitere:

	LXC-Container	Virtuelle Maschine
Kernel	der des Wirts	eigener
Startdauer	Sekundenbruchteile bis Sekunden	zehn Sekunden bis Minuten
Speicherbedarf	nur, was die Prozesse belegen	im Betrieb nahezu der zugewiesene Betrag
Gastbetriebssystem	nur Linux	beliebig
Kernelmodule laden	nein	ja
Migration im laufenden Betrieb	nein	ja
Abgrenzung	Prozessisolation	Hardwareisolation

Wann ein Container reicht

Für die meisten Dienste im Homelab. Konkret:

• Web- und Anwendungsdienste, die ohnehin nur Prozesse und Dateien brauchen.
• Datenbanken, solange sie nicht auf besondere Kernelfunktionen zugreifen.
• Netzwerkdienste wie DNS-Auflöser oder Reverse Proxies.
• Alles, wovon du mehrere Instanzen willst. Zehn Container kosten so viel Arbeitsspeicher, wie ihre Prozesse gerade belegen. Zehn VMs kosten nach einigen Betriebstagen nahezu ihren zugewiesenen Betrag – auch dann, wenn darin nichts passiert.

Der letzte Punkt ist im Homelab der entscheidende, und er wird meist falsch begründet. KVM belegt den Gastspeicher nämlich beim ersten Zugriff, nicht bei der Zuweisung: Eine frisch gestartete VM mit 8 GiB steht am Wirt zunächst mit einem Bruchteil davon in der Liste. „Zehnmal den zugewiesenen Betrag, und zwar sofort“ stimmt also nicht.

Nur bleibt es nicht dabei. Ein Linux-Gast füllt jeden freien Speicher mit Seitencache, und diese Seiten gibt er von sich aus nicht zurück – für den Wirt sind sie belegt, weil er nicht wissen kann, dass der Gast sie leicht entbehren könnte. Nach ein paar Tagen Betrieb steht die VM deshalb mit annähernd dem vollen Betrag da, ohne dass darin mehr liefe als am ersten Tag. Zurückholen lässt sich das nur über den Ballon-Treiber, und der greift erst, wenn der Wirt in Bedrängnis gerät.

Bei Containern stellt sich die Frage gar nicht: Ihre Prozesse liegen im Speicher des Wirts wie alle anderen auch, ungenutzter Speicher wird nie gebunden.

Wann es eine VM sein muss

Hier wird es konkret. Diese Fälle sind keine Geschmacksfrage.

Kein Linux

Windows, BSD, jedes andere Betriebssystem: VM. LXC kann nur, was auf dem Kernel des Wirts läuft.

Der Dienst braucht eigene Kernelmodule

Alles, was ein Modul lädt, gehört in eine VM. Der Container darf am Kernel des Wirts nichts ändern – zu Recht, denn ein Kernelmodul aus einem Container heraus wäre das Ende jeder Abgrenzung.

Typische Fälle: VPN-Software mit eigenem Treiber, Dateisysteme, die im Gast eingehängt werden sollen, alles rund um Erweiterungen der Paketfilterung.

Fremder Code mit Verwaltungsrechten

Ein Container teilt sich den Kernel mit dem Wirt und mit allen anderen Containern. Eine Lücke im Kernel wirkt damit über die Containergrenze hinweg. Eine VM hat diese Angriffsfläche nicht in derselben Form.

Faustregel: Alles, was aus dem Internet erreichbar ist und Software ausführt, die du nicht selbst kontrollierst, gehört in eine VM. Für den internen Dateidienst ist ein Container in Ordnung.

Der Gast soll ohne Unterbrechung umziehen

Proxmox migriert virtuelle Maschinen im laufenden Betrieb zwischen Knoten. Bei Containern geht das nicht – sie werden angehalten, verschoben und wieder gestartet.

Für die meisten Homelab-Dienste ist die kurze Unterbrechung gleichgültig. Wenn nicht, ist das ein Argument für die VM. Was dabei ohne gemeinsamen Speicher zu beachten ist, steht in Proxmox-Cluster ohne Shared Storage.

Docker im Container

Der Klassiker – und der Punkt, an dem am meisten Zeit verbrannt wird.

Docker in einem LXC-Container läuft, aber nur mit Zugeständnissen: Der Container braucht die Verschachtelung erlaubt, und je nach Speicherunterbau kommt der Docker-Speichertreiber ins Straucheln. In einem unprivilegierten Container kommen Rechteabbildungen dazu, die bei Datenträgereinbindungen zu Besitzverhältnissen führen, die niemand mehr durchschaut.

Es funktioniert. Es ist nur die Art von Aufbau, bei der man sechs Monate später vor einem Fehler steht und nicht mehr weiß, welche Sondereinstellung wofür da war.

Empfehlung: Docker in eine eigene VM. Der Aufpreis sind ein paar hundert Megabyte Arbeitsspeicher, der Gegenwert ist ein Aufbau, den auch die Dokumentation der jeweiligen Anwendung beschreibt.

Privilegiert oder unprivilegiert

Bei Containern kommt eine zweite Entscheidung dazu, die Proxmox beim Anlegen abfragt.

Unprivilegiert ist die Vorgabe und die richtige Wahl. Der root-Benutzer im Container ist auf dem Wirt ein gewöhnlicher Benutzer ohne Rechte. Bricht jemand aus, steht er vor einem unprivilegierten Konto.

Privilegiert braucht man selten. Der root im Container ist dann auch auf dem Wirt root – ein Ausbruch bedeutet die vollständige Übernahme.

Der Preis der unprivilegierten Variante ist die Rechteabbildung: Benutzerkennungen im Container werden auf einen hohen Bereich auf dem Wirt verschoben. Bei Verzeichniseinbindungen vom Wirt führt das zu Dateien, die im Container niemandem zu gehören scheinen. Das ist lösbar, aber es ist die Stelle, an der die meisten aufgeben und auf „privilegiert“ umstellen. Tu das nicht – eine VM ist die bessere Antwort auf dieses Problem als ein privilegierter Container.

Was bei der Sicherung anders ist

Beide Arten sichert Proxmox mit denselben Werkzeugen, aber das Ergebnis unterscheidet sich.

• Container werden als Dateiarchiv gesichert. Die Sicherung ist klein und lässt sich auch dateiweise durchsehen.
• VMs werden als Abbild ihrer virtuellen Datenträger gesichert. Die Sicherung ist größer, dafür kommt ein startfähiges System zurück.

Für beides gilt derselbe Modus: Ohne Snapshot-fähigen Speicher muss der Gast für die Dauer der Sicherung angehalten oder eingefroren werden. Welche Speicherarten das können, steht in Proxmox-Snapshots richtig nutzen; die Einrichtung der Sicherung selbst in Proxmox Backup Server einrichten.

Ein Punkt, der im Ernstfall zählt: Ein Container-Restore setzt einen passenden Wirt voraus. Die Sicherung enthält keinen Kernel. Bei einer VM ist das gleichgültig – sie bringt alles mit. Wer seine Notfallplanung ernst nimmt, hat das beim Restore-Test einmal durchgespielt.

Grafikkarten und andere Geräte

Ein Sonderfall, der oft übersehen wird: Für die gemeinsame Nutzung einer integrierten Grafikeinheit ist der Container die einfachere Lösung. Man reicht das Gerät durch, und mehrere Container können es gleichzeitig verwenden.

Eine VM braucht dafür die vollständige Durchreichung der Grafikkarte – aufwendiger, und das Gerät ist danach exklusiv belegt. Der Weg dorthin steht in GPU-Passthrough unter Proxmox.

Die Entscheidung in fünf Fragen

Der Reihe nach – die erste zutreffende Zeile gewinnt:

1. Kein Linux? → VM
2. Braucht Kernelmodule, oder soll Docker darin laufen? → VM
3. Öffentlich erreichbar und führt fremden Code aus? → VM
4. Muss ohne Unterbrechung zwischen Knoten wechseln? → VM
5. Sonst → Container

Punkt 5 trifft im Homelab häufiger zu, als die Diskussionen in Foren vermuten lassen.

Weiter im Cluster

• Proxmox VE im Homelab: der Einstieg – der Überbau
• Proxmox-Snapshots richtig nutzen – gilt für beide Arten, mit Unterschieden
• Proxmox-Cluster ohne Shared Storage – wo der Migrationsunterschied praktisch wird
• Proxmox Backup Server einrichten – sichert beides