LXC vs. VM auf Proxmox: Die richtige Isolation im Homelab
Die Einsteigerfrage, die das Proxmox-Modell offenlegt
Die Ausgangsfrage klang harmlos: Wann sollte man einen LXC-Container einsetzen und wann eine vollwertige VM? Dahinter verbarg sich jedoch genau jene Verunsicherung, die früher oder später fast jeden neuen Proxmox-Nutzer einholt. Der Fragesteller betrieb bereits einige schlanke Dienste in LXCs: Jellyfin, Pi-hole, nginx und vergleichbare Bausteine seines Homelabs. Dazu kamen zwei VMs, eine für eine eigene Docker-basierte Anwendung und eine weitere für Home Assistant. Doch dann kamen die Zweifel. Er hatte gelesen, dass Host-Updates LXC-Container beschädigen können, weil Container den Kernel des Hosts teilen, während VMs autarker arbeiten. Plötzlich wirkte die zuvor aufgeräumte Architektur riskant.
In diese Denkfalle tappt man schnell. Zu Beginn wirken LXCs wie die naheliegende Antwort: Sie sind schnell, leichtgewichtig und im Handumdrehen gestartet. Doch sobald jemand Kernel-Sharing, Container-Escapes oder Update-Probleme erwähnt, schlägt das Pendel oft radikal in die Gegenrichtung aus und alles soll in VMs verpackt werden. Erfahrene Anwender handhaben das selten so dogmatisch. Der pragmatischste Rat aus der Diskussion lautete schlicht, für viele Standarddienste im Homelab standardmäßig auf LXCs zu setzen und dann zu VMs zu greifen, wenn Isolation, Software-Paketierung, Docker-Stacks oder spezielle Betriebssysteme dies zur saubereren Wahl machen.
Diese Antwort wirkt auf den ersten Blick vielleicht wenig spektakulär, weil sie sich nicht als starres Gesetz festschreiben lässt. Es ist eine Ermessensentscheidung. Proxmox stellt Ihnen beide Werkzeuge bereit, weil beide ihre Berechtigung haben. Der Schlüssel liegt darin zu verstehen, welche Art von Problem Sie vermeiden möchten, statt aus der Wahl eine Glaubensfrage zu machen.
LXCs sind leicht, schnell und näher am Systemkern
Die Argumente für LXCs überzeugen sofort. Sie sind ressourcensparend, starten blitzschnell, verbrauchen weniger RAM und CPU und nutzen den vorhandenen Speicherplatz effizienter aus. Sie können Ordner des Hosts direkt einbinden, ohne dass man alles als Netzwerkfreigabe konfigurieren muss. Zudem harmonieren sie hervorragend mit granularen Proxmox-Backups, Snapshots, Bind-Mounts, softwaredefinierten Netzwerken (SDN) und genau jener Struktur kleiner Einzelkomponenten, die man im Homelab gerne aufbaut: ein Pi-hole hier, ein nginx-Reverse-Proxy dort, eine AdGuard-Instanz, Navidrome, Immich oder Medienhelfer. Dafür eignen sich Container perfekt.
Ein Nutzer fasste den Vorzug prägnant zusammen: Wenn Sie Dienste aus einer einzigen riesigen Docker-VM herausnehmen und in separate LXCs aufteilen, gewinnen Sie die direkte Kontrolle auf Proxmox-Ebene über jeden einzelnen Dienst zurück. Fällt ein Dienst aus, stellen Sie gezielt diesen einen Container wieder her. Benötigt ein Dienst Speicherplatz auf abweichende Weise, passen Sie nur diesen an. Ist vor einem Update ein Snapshot fällig, müssen Sie nicht gleich einen ganzen Stapel unzusammenhängender Anwendungen einfrieren. Diese Granularität macht den Reiz aus: Viele kleine LXCs wirken wie eine ordentlich sortierte Schublade statt wie eine unübersichtliche Kiste mit der Aufschrift „Docker“.
Genau das, was LXCs so performant macht, sorgt bei manchen Nutzern allerdings für Unbehagen. Sie teilen sich den Kernel des Hosts und stützen sich auf Linux-Namespaces und Prozess-Isolation statt auf ein vollständig getrenntes Gastbetriebssystem. Ein schwerwiegender Kernel-Bug wiegt deshalb potenziell schwerer als innerhalb einer VM. Einige Anwender verwiesen auf Linux-Sicherheitslücken (CVEs) und Diskussionen über Container-Escapes als Argument dafür, VMs grundsätzlich als sicherere Wahl für erreichbare Dienste einzustufen. Andere hielten dagegen, dass das pauschale Argument „VMs sind sicherer“ aus einer Zeit stamme, bevor unprivilegierte Container zum Standard wurden.
Beide Positionen haben einen wahren Kern. LXCs sind keine Spielzeuge, aber sie sind eben auch keine VMs. So zu tun, als gäbe es keinen Unterschied, führt auf beiden Seiten zu fragwürdigen Designentscheidungen.
VMs wiegen schwerer, bieten aber eine echte Schutzwand
Das stärkste Argument für virtuelle Maschinen bleibt die harte Isolation. Eine VM führt ein vollständig eigenes Betriebssystem mit eigenem Kernel aus. Das macht sie zwar nicht unbezwingbar, errichtet aber eine deutlich robustere Grenze. Wenn Sie einen Dienst betreiben, der öffentlich aus dem Internet erreichbar ist, Datenverkehr von Unbekannten entgegennimmt oder Software ausführt, der Sie nicht bedingungslos vertrauen, rechtfertigt diese zusätzliche Mauer den Ressourcen-Overhead. Ein Kommentar brachte es auf den Punkt: Alles, was echten öffentlichen Traffic erwartet, gehört in der Regel in eine gründlich abgesicherte VM.
Gleichzeitig muss nicht jeder öffentlich erreichbare Webdienst zwingend in einer VM laufen. Mehrere Anwender betonten, dass Reverse-Proxys, vorgeschaltete Authentifizierung (Forward Auth), Identity-Provider wie Authentik, OIDC, VPN-Netzwerke wie Netbird oder Werkzeuge wie CrowdSec das praktische Risiko erheblich senken. Das entspricht dem Prinzip der gestaffelten Sicherheit: Exponieren Sie Dienste nicht direkt, schalten Sie eine Authentifizierung davor, beschränken Sie den Zugriff und halten Sie den potenziellen Schadensradius klein. Für ein Homelab, in dem lediglich Freunde oder Familienmitglieder auf Dienste zugreifen, genügt das oft völlig. Handelt es sich jedoch um einen wirklich offenen Dienst, insbesondere mit komplexem Code oder sensiblen Daten, ist eine VM keine Paranoia, sondern eine günstige Versicherung.
VMs gewinnen außerdem immer dann, wenn Software erwartet, ein vollständiges System für sich allein zu haben. Home Assistant OS ist das klassische Beispiel aus der Diskussion. Viele Nutzer betreiben es bewusst als eigenständige Appliance-VM, weil dieser Weg offiziell unterstützt wird, einfach einzurichten ist und kaum Wartungsaufwand erfordert. NAS-Betriebssysteme sind ein weiterer typischer Fall, speziell wenn PCIe- oder HBA-Controller per Passthrough durchgereicht werden. Auch für umfangreiche, zentral verwaltete Docker-Compose-Umgebungen bleibt eine VM der natürliche Ort, wenn Sie Anwendungen nach klassischer Docker-Manier verwalten wollen, anstatt jeden Dienst einzeln in einen LXC zu überführen.
Dafür nimmt man Kompromisse in Kauf. VMs beanspruchen mehr CPU, RAM und Plattenplatz, starten spürbar langsamer und gestalten die direkte Dateifreigabe mit dem Host oft umständlicher. Zudem verdecken sie Details vor dem Hypervisor: Proxmox sieht lediglich die VM, nicht aber die einzelnen Prozesse darin. Das muss kein Nachteil sein, wenn man bewusst eine dedizierte Medien-VM oder eine VM für Netzwerkwerkzeuge betreiben möchte. Es ist jedoch ein anderer Verwaltungsstil: Sie entscheiden sich für einen dickeren Tresor statt für leichtere Fächer.
Docker in einer VM, Docker im LXC oder gar kein Docker
Beim Thema Docker reden viele Administratoren aneinander vorbei. Das ursprüngliche Setup des Nutzers bestand aus einer VM, auf der eine eigene Anwendung unter Docker lief. Viele Anwender schätzen Docker innerhalb einer VM, weil die Docker-Umgebung dadurch sauber gekapselt bleibt. Sie können die gesamte VM unkompliziert sichern und wiederherstellen, ohne sich mit verschachtelter Containerisierung (Docker im LXC) auseinandersetzen zu müssen. Ein Kommentator erläuterte, dass er Docker-Container in thematisch getrennten VMs betreibt, beispielsweise getrennt nach Medien und Netzwerk-Tools. Das verbindet Isolation mit einer übersichtlichen Gruppierung.
LXC-Befürworter halten dagegen und fragen, warum man jeden Dienst in Docker innerhalb einer VM packen sollte, wenn Proxmox den Dienst direkt als eigenständigen LXC-Container verwalten kann. Aus ihrer Sicht fügt Docker eine unnötige Zwischenschicht hinzu, schafft zusätzliche Backup-Fragen und vermischt Anwendungszustand mit Systemzustand. Wenn Jellyfin, Pi-hole, nginx, AdGuard oder Navidrome sauber direkt im LXC laufen, bietet Proxmox dafür native Backups, Snapshots, Speicher-Mounts und einfache Wiederherstellung. Geht ein Update bei Immich schief, rollt man den Container vom Vortag zurück und arbeitet weiter.
Docker bietet hingegen klare Vorteile bei der Bereitstellung und bei Updates von Standardanwendungen. Compose-Dateien sind portabel, weit verbreitet und ausführlich dokumentiert. Viele Open-Source-Projekte liefern heute primär Docker-Anleitungen aus. Manche Administratoren möchten schlicht nicht jede Anwendung manuell in eine LXC-Umgebung übertragen, sondern bevorzugen eine Docker-VM, um Software exakt so zu betreiben, wie der Entwickler es vorsieht. Das ist ein völlig legitimer Ansatz.
Docker in einer VM ist daher keineswegs falsch, und LXCs sind nicht automatisch in jedem Szenario die elegantere Lösung. Die Entscheidung hängt davon ab, auf welcher Ebene Sie Anwendungsgrenzen ziehen möchten. Docker Compose eignet sich hervorragend, wenn Sie App-Stacks als Code verwalten wollen. Proxmox-LXCs glänzen, wenn jeder Dienst als vollwertige Verwaltungseinheit im Hypervisor sichtbar sein soll. Eine VM ist optimal, wenn Sie eine klare Grenze um einen gesamten Stack ziehen und sich nicht um Eigenheiten des Host-Systems kümmern möchten.
Die Sicherheitsdebatte: Warum alle ein Stück weit recht hatten
Im Verlauf der Diskussion driftete der Thread rasch in Grundsatzfragen zur Sicherheit ab. Ein Kommentator argumentierte, der Vorzug einer VM reiche weit über „bessere Isolation“ hinaus: Eine VM sei eine echte virtualisierte Umgebung, während ein LXC als Containerprozess direkt auf dem Host läuft, vergleichbar mit einer weiterentwickelten chroot-Trennung. Ein anderer hielt dagegen, dass moderne unprivilegierte Container alte Sicherheitsbedenken weitgehend entkräftet hätten. Daran schlossen sich Debatten über AppArmor, Kernel-Exploits und die Frage an, ob bestimmte Ausbruchsmechanismen gepatcht, umgangen oder nur unter speziellen Randbedingungen relevant seien.
An diesem Punkt fühlen sich viele Einsteiger überfordert. Die praktische Antwort fällt deutlich bodenständiger aus als der theoretische Disput. Eine VM bildet die stärkere Isolationsgrenze, während ein unprivilegierter LXC für übliche Homelab-Dienste, die nicht ungeschützt im Internet hängen, in der Praxis völlig ausreicht. LXCs isolieren nicht so strikt wie VMs, aber ihr Einsatz ist keineswegs leichtsinnig.
Der entscheidende Fehler besteht darin, Sicherheit als einfachen Ein-Aus-Schalter zu begreifen. Ein exponierter Dienst in einer schlecht gepflegten VM mit schwachen Passwörtern und offenen Ports bleibt ein ernstes Sicherheitsrisiko. Ein interner LXC hinter einem VPN und vorgeschalteter Authentifizierung, der regelmäßig aktualisiert und gesichert wird, stellt hingegen ein sehr solides Homelab-Setup dar. Isolation ist ein wichtiger Faktor, doch Netzwerkdesign, Patch-Disziplin, Authentifizierung, Zugriffsrechte, Backups und ein praxiserprobter Wiederherstellungsweg wiegen in der Summe oft schwerer.
Der hilfreichste Rat bestand darin, Risiken differenziert einzustufen, statt pauschal vor LXCs zurückzuschrecken. Für öffentlich erreichbare, nicht vertrauenswürdige, unternehmenskritische oder besonders sensible Workloads ist eine VM die richtige Wahl. Für interne Dienste, schlanke Anwendungen mit bekanntem Nutzerkreis und unkomplizierten Wiederherstellungswegen genügt ein LXC vollauf. In dieser pragmatischen Mitte entstehen die meisten tragfähigen Infrastrukturentscheidungen.
Die Faustregel: LXCs nutzen, bis eine VM echte Vorteile bietet
Für alle, die auf ihrem Proxmox-Host nach einer klaren Orientierung suchen, lieferte die Diskussion eine sehr praxistaugliche Faustregel. Nutzen Sie LXCs für leichtgewichtige Linux-Dienste, insbesondere für Pi-hole, AdGuard, nginx, einfache Mediensammlungen, Monitoring-Tools und Anwendungen, bei denen Sie von kurzen Startzeiten, geringem Overhead, direkten Speicher-Mounts und nativen Proxmox-Backups profitieren. Greifen Sie zu einer VM, wenn Software als fertige Appliance verteilt wird, wenn Sie ein separates Betriebssystem benötigen, wenn Sie Home Assistant OS betreiben, wenn Sie umfangreiche Docker-Compose-Setups bevorzugen, wenn Hardware-Passthrough eine vollständige Maschine voraussetzt oder wenn harte Isolation das primäre Ziel darstellt.
Für viele dieser schlanken LXC-Dienste wie Pi-hole, AdGuard und zahlreiche weitere existieren bereits Ein-Zeilen-Installationen in der Sammlung der Proxmox VE Helper Scripts, was den manuellen Bau einzelner Container überflüssig macht.
Daraus folgt auch, dass das ursprüngliche Setup des Nutzers im Kern stimmig war: Home Assistant in einer VM ist sinnvoll. Eine eigene Docker-Anwendung in einer VM ist passend, wenn Docker das gewünschte Bereitstellungsmodell darstellt. Jellyfin, Pi-hole, nginx und vergleichbare Dienste in LXC-Containern laufen zu lassen, ist ebenso folgerichtig. Es gibt keinen Grund, LXCs zu meiden; man sollte lediglich nicht erwarten, dass ein einziger Containertyp jede erdenkliche Aufgabe optimal löst.
Hinzu kommt ein Wiederherstellungsaspekt, den Einsteiger leicht übersehen. Erhält jede Anwendung ihren eigenen LXC-Container, zieht der Ausfall einer Anwendung nicht automatisch die anderen in Mitleidenschaft. Backups fallen kleiner und gezielter aus, und Wiederherstellungen lassen sich punktgenau vornehmen. Eine große VM voller Docker-Container mag bequemer zu aktualisieren sein; gerät jedoch das Dateisystem der VM oder der Docker-Daemon durcheinander, müssen Sie unter Umständen einen ganzen Häuserblock wiederherstellen, bloß weil in einer Wohnung das Waschbecken übergelaufen ist. Kein Modell ist perfekt: Wählen Sie das Fehlerszenario, das Sie im Ernstfall lieber debuggen möchten.
Die erfahrensten Stimmen in der Runde versuchten gar nicht erst, eine theoretische Idealform durchzusetzen. Sie kombinierten beide Welten, was dem eigentlichen Wesen von Proxmox entspricht: VMs für harte Trennwände, LXCs für Tempo und Granularität, Docker dort, wo es den Betrieb erleichtert, und PBS-Backups über alle Ebenen hinweg, ohne daraus eine ideologische Grundsatzfrage zu machen.
Durchdachte Architektur schlägt Verunsicherung
Die Sorge, dass ein Host-Update LXC-Container beeinträchtigen könnte, ist nicht völlig unbegründet. Da Container den Host-Kernel mitnutzen, können Änderungen auf dem Host direkte Auswirkungen haben. Das macht LXCs keineswegs unbrauchbar; es bedeutet lediglich, dass Sie Updates überlegt einspielen, regelmäßige Backups anlegen und nicht sämtliche kritischen Dienste unbedacht an einer einzigen Stelle bündeln sollten. VMs arbeiten zwar autonomer, verbrauchen dafür mehr Ressourcen, erfordern zusätzlichen Verwaltungsaufwand und schützen Sie ebenfalls nicht vor Fehlern bei Architektur, Backup oder Netzwerkkonfiguration.
Die Diskussion hat gezeigt, dass Einsteiger in Proxmox weniger abstrakte Definitionen benötigen als vielmehr einen klaren Entscheidungsrahmen. Fragen Sie sich: Um was für einen Dienst handelt es sich? Wie stark ist er exponiert? Wie sehr vertrauen Sie dem Code? Wie soll er installiert werden? Wie aufwendig wäre eine Wiederherstellung? Welcher Speicher wird benötigt? Ist direkter Hardwarezugriff erforderlich? Und steht Isolation oder Granularität im Vordergrund? Die passende Antwort ergibt sich daraus fast von selbst.
Für das Homelab bleibt das Fazit erfreulich pragmatisch: LXCs für die meisten internen, vertrauenswürdigen Dienste und VMs für Home Assistant OS, große Docker-Stacks, öffentlich erreichbare Workloads, Appliance-Systeme sowie alles, was eine dickere Schutzmauer rechtfertigt. Verglichen mit dem Ansatz, ausnahmslos alles in VMs zu sperren, bietet diese Aufteilung ein deutlich besseres mentales Modell.
Das Beste an Proxmox ist, dass es Ihnen keine starre Vorgabe aufzwingt. Es erlaubt Ihnen, genau jenen pragmatischen, sinnvollen Hybridansatz zu wählen, der zu Ihren Anforderungen passt. Ein Pi-hole benötigt keine Festung, Ihre öffentlich erreichbare Web-App hingegen womöglich schon. Ihre Home-Assistant-Instanz möchte vielleicht eine in sich geschlossene Appliance sein, während Ihre Medienwerkzeuge als Container mit direkten Mounts und schnellen Backups am besten aufgehoben sind. Ein solches Setup mag auf dem Papier uneinheitlich wirken; in der Praxis ist es das Kennzeichen einer erwachsenen Infrastruktur.