Proxmox 9.2 ist da, und die Homelab-Community streitet schon darüber, was „besser“ eigentlich bedeuten soll

Das Release ist gelandet, und die Wunschliste wurde lauter

Proxmox 9.2 kam nicht leise daher. Ein Release-Post sammelte Hunderte Upvotes und fast hundert Kommentare, was einiges darüber aussagt, wo diese Plattform gerade steht. Es ist nicht nur ein weiteres Virtualisierungs-Update für Leute, die blinkende Rack-Lichter mögen. Es ist zum Zentrum einer größeren Verschiebung geworden: Homelab-Bauer, kleine Firmen und VMware-Flüchtlinge beobachten Proxmox aufmerksamer als je zuvor. Jedes Release muss inzwischen zwei sehr unterschiedliche Lager gleichzeitig zufriedenstellen: Menschen, die langweilige, stabile Infrastruktur wollen, und Menschen, die wollen, dass Proxmox zum Alles-Dashboard für Compute, Storage, Container, Backups, Replikation und alles andere wird, das sie leid sind, mühsam zusammenzuflicken.

Diese Spannung zog sich durch die gesamte Diskussion. Manche Nutzer waren begeistert von den praktischen Verbesserungen, vor allem beim LXC-Identity-Mapping. Andere forderten sofort erstklassige OCI-Container-Unterstützung, damit sie nicht mehr Docker in einem LXC laufen lassen müssen wie eine Art Matroschka mit Vertrauensproblemen. Ein paar Leute wollten mehr Feinschliff bei der Orchestrierung. Andere widersprachen entschieden und argumentierten, Proxmox sei ein Hypervisor, kein Docker Compose mit hübscherem Login-Bildschirm. Das Lustige daran: Beide Lager klingen vernünftig. Genau das macht dieses Release interessant. Proxmox 9.2 hat nicht nur Features ausgeliefert. Es hat die Debatte darüber neu eröffnet, was Proxmox eigentlich werden soll.

Der UID-Mapping-Schmerz bekam endlich eine menschliche Antwort

Die glücklichste Ecke des Threads drehte sich um UID- und GID-Mapping für unprivilegierte LXCs. Das klingt schmerzhaft nischig, bis man einmal versucht hat, Host-Datasets per Bind-Mount in Container einzubinden, ohne dass die Berechtigungen zum Tatort werden. Dann wird daraus die Art von Feature, bei dem erwachsene Menschen schreiben: „Von außen betrachtet mag es traurig wirken, dass mich so etwas glücklich macht.“ Ehrlich gesagt, fair. Wer je lange genug auf lxc.idmap-Zeilen gestarrt hat, um seine Lebensentscheidungen zu hinterfragen, für den fühlt sich ein sauberer, GUI-gesteuerter Mapping-Flow wie eine warme Decke an.

Ein Kommentator zeigte die alte Welt in ihrem ganzen Schrecken: ein Haufen lxc.idmap-Einträge, die Blöcke von UIDs und GIDs zwischen Host und Container abbilden. Die Konfiguration sah aus wie etwas, das man um 1:17 Uhr aus einem Forenpost kopiert und danach nie wieder anfasst, weil das Ändern einer einzigen Zahl einen Berechtigungsdämon heraufbeschwören könnte. Der neue Ansatz ist laut den Nutzern eher: „Auswählen, welche Container-UIDs und -GIDs auf welche Host-IDs gemappt werden.“ Das ist die Art Verbesserung, die auf keiner Keynote glänzt, aber den Alltag von Leuten, die Media-Server, Download-Clients, NFS-Mounts, ZFS-Datasets und geteilten Storage über mehrere Container hinweg betreiben, absolut verändert.

Es gab auch etwas Erleichterung darüber, /etc/subuid und /etc/subgid nicht mehr in der alten Art anfassen zu müssen. Für viele Homelab-Nutzer sind das die Dateien, an denen das Selbstvertrauen stirbt. Man weiß, dass sie wichtig sind. Man weiß, dass das Sicherheitsmodell mit unprivilegierten Containern besser ist. Aber man weiß auch: Ein einziger falscher Mapping-Fehler, und die eigenen Dateien gehören plötzlich mysteriösen Zahlen, die aussehen, als kämen sie von einem außerirdischen Steuerformular. Also nehmen Leute Abkürzungen. Sie fahren privilegierte Container. Sie chmoden zu großzügig. Sie sagen sich, das räumen sie später auf. Proxmox 9.2 scheint genau auf diese unordentliche Mitte zu zielen: nicht die Komplexität zu entfernen, sondern sie endlich überlebbarer zu machen.

„Einfach 777 nehmen“ ist lustig, bis es zur Policy wird

Die Berechtigungsdiskussion wurde schnell ernst, weil hier jeder ein Geständnis hat. Jemand scherzte über das Leben mit 777, praktisch ein Eingeständnis, dass die sauberste Lösung nicht immer die ist, die Leute tatsächlich nutzen. Ein anderer antwortete, 777 sei in einem Homelab mit wenigen Nutzern, ZFS-Snapshots und Backups „akzeptabel“, aber auf keinen Fall bei der Arbeit. Diese Spaltung ist die Proxmox-Kultur im Kleinen. Die eine Hälfte des Raums baut zu Hause Enterprise-artige Gewohnheiten auf. Die andere Hälfte versucht nur, Jellyfin dazu zu bringen, die Filme zu sehen, ohne das Wochenende mit dem Lernen von Linux-User-Namespaces zu verbringen.

Das Problem ist, dass Homelab-Abkürzungen dazu neigen, dauerhafte Architektur zu werden. Man macht ein Dataset weit offen mit chmod, weil man müde ist. Sechs Monate später hängen fünf Container davon ab, zwei Dienste schreiben darauf, und man weiß nicht mehr, wem was gehören sollte. Jemand im Thread beschrieb die Verwaltung unterschiedlicher UIDs und GIDs über Host-Datasets und LXCs hinweg als praktisch unmöglich zu verfolgen und zu pflegen. Das ist keine Anfängerbeschwerde. Das ist der Klang eines Systems, das über seinen ursprünglichen Plan hinausgewachsen ist.

Es gab auch einen klugen Gegeneinwand. Ein Kommentator sagte, viele Tutorials würden das Mapping für die meisten Fälle überkomplizieren, und man könne das Problem manchmal lösen, indem man einen Host-Nutzer mit einem UID-Offset anlegt, das sich natürlich in den LXC einordnet. Ein anderer bevorzugte, wo immer möglich „echte“ Host-IDs zu verwenden, weil das künftige Umzüge einfacher macht. Ihr Beispiel war simpel: Was, wenn qBittorrent von einem LXC in eine VM mit virtiofs umzieht? Wenn alles hinter Container-Offset-Eigentümerschaft festhängt, landet man womöglich bei einer riesigen chown-Migration. Das ist die Art von unspektakulärer, praktischer Weitsicht, die ganze Wochenenden rettet.

Deshalb ist das neue Mapping-Feature wichtig. Es ist nicht nur eine GUI-Nettigkeit. Es ist ein Druckablassventil für Jahre an Community-Hacks, kopierten Konfigurationen, Berechtigungsangst und „das fixe ich später“-Storage-Layouts. Proxmox muss Linux-Berechtigungen nicht einfach machen. Das wäre nach irgendeinem uralten Sysadmin-Vertrag vielleicht sogar verboten. Aber es kann sie weniger feindselig machen, und das ist eine große Sache.

Der OCI-Traum schwebt weiter über allem

Der andere große emotionale Thread drehte sich um OCI-Container. Die Leute wollen sie. Dringend. Ein Nutzer sagte, er hoffe auf erstklassige OCI-Unterstützung, damit er kein Docker-LXC mehr betreiben muss und alles über die Proxmox-UI verwalten kann, inklusive Replikation, HA und der restlichen eingebauten Plattform-Maschinerie. Das ist der Traum: keine Container-Plattform mehr innerhalb eines Containers, kein halboffizieller Stack mehr, keine mentale Aufspaltung mehr zwischen „Proxmox-Dingen“ und „Docker-Dingen“. Nur noch ein Ort, um Workloads auszuführen und zu verwalten.

Aber diese Idee lief sofort gegen die Wand von „Was soll Proxmox eigentlich sein?“ Jemand fragte, was aktuell tatsächlich fehle: nur die UI, oder auch das Backend? Eine andere Person antwortete frustriert, im Vergleich zu Docker-artigen Workflows fehle Proxmox „so ziemlich alles außer der Fähigkeit, überhaupt Container auszuführen“: Orchestrierung, Compose, Tooling. Dann kam der Widerspruch. Docker Compose sei ein Feature auf Docker-Ebene, kein Feature auf Hypervisor-Ebene, argumentierte ein Kommentator. Unterschiedliche Ebenen. Unterschiedliche Aufgaben.

Diese Uneinigkeit ist größer als Proxmox 9.2. Es geht um Plattform-Gravitation. Sobald ein Tool zum Zentrum der Infrastruktur von jemandem wird, wollen Nutzer natürlich, dass es mehr Aufgaben übernimmt. Proxmox handhabt bereits VMs und LXCs. Es hat bereits Replikation, HA, Storage, Backups, Clustering und eine starke Web-UI. Warum also nicht auch OCI-Container? Warum nicht Compose-artige Workflows? Warum den Leuten nicht erlauben, Apps direkt dort zu verwalten, wo die Rechenleistung ohnehin schon läuft?

Die konservative Antwort lautet, dass zu viel zu schlucken eine Plattform aufgebläht und verwirrend machen kann. Proxmox ist stark, weil es seine Kernaufgabe kennt: virtuelle Infrastruktur. Wenn es versucht, gleichzeitig Kubernetes-lite, Docker Desktop, Portainer und Hypervisor zu werden, könnte es die klare Kante verlieren, die dafür sorgt, dass Leute ihm vertrauen. Die ambitionierte Antwort lautet, dass sich die Welt verändert hat und Container keine Nebenquest mehr sind. Eine moderne Virtualisierungsplattform, die OCI nicht als erstklassigen Bürger versteht, könnte anfangen, unvollständig zu wirken, besonders für Nutzer, die als Workaround bereits Docker in LXCs betreiben.

Homelab-Nutzer wollen Enterprise-Features, aber mit weniger Enterprise-Kopfschmerzen

Was die Proxmox-Community so interessant macht, ist, dass die Grenze zwischen Homelab und Produktion immer verschwommener wird. Leute betreiben Cluster im Keller, sichern die Familieninfrastruktur, als wäre sie eine kleine Firma, testen HA, bauen Storage-Pools und verwalten Identitäten über Container hinweg. Und dann geben sie zu, dass sie 777 nutzen, weil Berechtigungs-Mapping ihnen Kopfschmerzen bereitet hat. Diese Kombination ist chaotisch, aber genau deshalb hat Proxmox Momentum. Es lässt Leute in bessere Praktiken hineinwachsen, ohne sie zu zwingen, am ersten Tag zu Enterprise-Architekten zu werden.

Deshalb hat 9.2 mit seinen praktischen Fixes eine so starke Reaktion ausgelöst. Das Release ist nicht nur wegen der Versionsnummer spannend. Es ist spannend, weil es die kleinen Ärgernisse abträgt, die Nutzer zwingen, zwischen Sicherheit und geistiger Gesundheit zu wählen. Unprivilegierte Container sind besser, aber wenn das Einbinden von Host-Storage darin unmöglich erscheint, meiden Leute sie. Geteilte Datasets sind mächtig, aber wenn Berechtigungen unnachvollziehbar werden, greifen Leute zu gefährlichen Abkürzungen. Docker in LXC funktioniert, aber wenn es sich für immer wie ein Workaround anfühlt, fragen sich Leute, warum die Plattform ihnen nicht entgegenkommen kann.

Dahinter steht auch ein sehr realer professioneller Schatten. Proxmox wird zunehmend als Alternative zu größeren, teureren Virtualisierungs-Stacks bewertet. Das erhöht die Erwartungen. Heimnutzer tolerieren vielleicht etwas Eigenwilligkeit. Enterprise-Nutzer wollen sauberes Lifecycle-Management, vorhersehbare Upgrades, offizielles Tooling, dokumentierte Pfade und weniger „kopiere diesen Config-Blob und bete“-Momente. Jedes Release muss inzwischen beide Zielgruppen tragen: die Person mit dem Mini-PC unter dem Schreibtisch und den Admin, der prüft, ob Proxmox eine Plattform ersetzen kann, die plötzlich zu teuer oder zu nervig geworden ist.

Die besten Teile von 9.2 scheinen genau auf diese Überschneidung zu zielen. Schwierige Dinge klarer machen. Fragile Konfiguration in unterstützte UI-Pfade verschieben. Die Zahl handeditierter Dateien reduzieren. Sicherere Standardwerte liefern, ohne Power-Usern zu verbauen, absichtlich seltsame Dinge zu tun. Das ist der Proxmox-Sweetspot.

Das Release fühlt sich wie Fortschritt an, nicht wie eine Ziellinie

Proxmox 9.2 landete mit genau der Art Reaktion, die sich wohl jedes Infrastrukturprojekt wünscht: Begeisterung, gemischt mit sofortigen Forderungen nach mehr. Die Leute bemerkten die Verbesserungen. Sie schätzten die Arbeit. Dann fingen sie an, nach der nächsten Ebene zu fragen, weil Infrastruktur-Nutzer nie fertig sind. Heute ist es UID-Mapping. Morgen ist es OCI. Dann Orchestrierung. Dann sauberere Storage-Workflows. Dann bessere Migrationspfade. Dann mehr Feinschliff bei HA. Der Preis dafür, zentral im Leben von Menschen zu werden, ist, dass sie anfangen zu wollen, dass man alles löst.

Das ist kein schlechtes Problem. Es bedeutet, dass Proxmox wichtig ist. Es bedeutet, dass die Plattform über „billige VMware-Alternative“ hinausgewachsen ist, hin zu etwas mit eigener Kultur, eigenen Erwartungen und eigenem Roadmap-Druck. Aber die Community-Reaktion zeigt auch das Risiko: Proxmox kann nicht einfach jedem Wunschlisteneintrag hinterherjagen. Es muss sorgfältig auswählen. Erstklassige OCI-Unterstützung könnte enorm sein, aber nur, wenn sie zur Plattform passt, statt sie in einen verwirrten App-Manager zu verwandeln. Verbesserungen beim Berechtigungs-Mapping sind großartig, weil sie Schmerz reduzieren, ohne zu verändern, was Proxmox im Kern ist. Das ist das Modell.

Das emotionale Zentrum des Releases ist eigentlich einfach: Die Leute wollen, dass Proxmox weiter einfacher wird, ohne dabei dümmer zu werden. Sie wollen Enterprise-Grade-Features ohne Enterprise-Grade-Elend. Sie wollen, dass die UI sie vor Config-Datei-Gymnastik bewahrt, aber sie wollen die Shell trotzdem noch da haben, wenn es seltsam wird. Sie wollen, dass sich Container, VMs, Storage und Backups wie ein System anfühlen, nicht wie ein Haufen benachbarter Tools, zusammengehalten von Notizen aus drei Forenposts und einer Bash-History.

Proxmox 9.2 beantwortet nicht jeden dieser Wünsche. Das war nie zu erwarten. Aber es scheint eine ganz konkrete Frustration zu beantworten: Ein Teil der hässlichsten Arbeit an Container-Storage-Berechtigungen kann endlich weniger hässlich werden. Für eine normale Person klingt das langweilig. Für die Leute, die Proxmox zu Hause und bei der Arbeit betreiben, ist das die Art von Langeweile, die alles verändert.