Proxmox 8 auf 9 lief so reibungslos, dass die Leute ihrer eigenen Nervosität misstrauten
Große Infrastruktur-Upgrades kommen normalerweise mit einer kleinen rituellen Portion Angst daher. Backups werden doppelt geprüft, Release Notes werden angestarrt wie Rechtsdokumente, und jeder Admin stellt sich still den einen verfluchten Dienst vor, der nicht wieder hochkommt. Genau deshalb schlug das Lob für den Sprung von Proxmox VE 8 auf 9 so ein. Ein Besitzer eines Heimservers führte das Upgrade in-place von PVE 8.4.19 auf 9.2.3 durch, ließ pve8to9 --full laufen, folgte dem Wiki, wechselte die Repos, machte das Dist-Upgrade, startete neu — und bekam genau das, was sich jeder Admin wünscht: kein Drama, keine Überraschungen, keine seltsame archäologische Grabung durch kaputte Pakete. Danach kaufte die Person ein Community-Abo, weil sich Politur wie diese nicht von selbst pflegt.
Das Checklisten-Tool war der eigentliche Held
Der Star des Threads war kein glänzendes neues Feature. Es war der Upgrade-Checker. Der ursprüngliche Poster sagte, pve8to9 --full habe alles Relevante gefunden, noch bevor das Upgrade überhaupt begann. Das ist die Art von Tooling, die man unterschätzt, bis sie einen vor sich selbst rettet. Ein großer Versionssprung ist beängstigend, weil die Unbekannten überall lauern: Repositories, Bootloader, Container, individuelle Kernel-Bausteine, Storage, Netzwerkkarten, alte Konfigurationsentscheidungen, die man vor drei Jahren getroffen und längst vergessen hat. Eine gute Checkliste macht aus unsichtbarer Gefahr eine To-do-Liste.
Mehrere Leute bestätigten dieses Vertrauen. Ein Kommentator sagte, das eigene Upgrade sei nahtlos verlaufen, obwohl man selbst „bei Unix/Linux/etc. ziemlich unfähig" sei, und fügte hinzu, das 8-auf-9-Skript sage einem, was hochgehen würde, sodass man es in Ruhe reparieren könne. Eine andere Person führte das Upgrade auf etwa neun Nodes durch, darunter einen Sieben-Node-Cluster, und sagte, fast alle seien problemlos gelaufen. Die eine Ausnahme war ein Anwenderfehler, nicht Proxmox, und selbst dieser Node überlebte nach zusätzlicher Arbeit. Das ist keine Magie. Das fühlt sich an wie gute Leitplanken.
Einfache Setups hatten die beste Zeit
Der ursprüngliche Beitrag verkaufte die Erfahrung bewusst nicht übertrieben. Das eigene Setup war einfach: ein einzelner Standalone-Node, kein Ceph, kein Cluster, kaum Anpassungen. Man gab offen zu, dass diese Einfachheit einen großen Teil der Schwerstarbeit übernommen hatte und dass es vermutlich half, mit dem Upgrade zu warten, bis 9.x gereift war. Diese Ehrlichkeit war wichtig, weil sie verhinderte, dass das Lob zu „jeder sollte jetzt sofort upgraden und aufhören, sich Sorgen zu machen" wurde. Ein vanilla Host ist die einfache Spur. Trotzdem ist es feiernswert, dass die einfache Spur sauber funktionierte.
Die Kommentare machten das deutlich. Manche Nutzer fühlten sich beruhigt genug, um ihre Upgrade-Zeitpläne zu überdenken. Eine Person hatte gezögert, weil nach eigener Erfahrung jede größere Änderung rund 10 Prozent der Dinge kaputt macht. Auch bei ihr lief nichts allzu Kompliziertes, aber wenn ausgerechnet die falschen 10 Prozent kaputtgehen, kann ein Neuaufbau echte Zeit fressen. Nach dem Lesen der Erfolgsgeschichte erwog die Person, das Upgrade von „Sommerurlaubsprojekt" zu „langes Wochenendprojekt" hochzustufen. Das ist die Kraft eines langweiligen Erfolgsberichts. Er gibt nervösen Leuten einen Boden, auf dem sie stehen können.
Dann meldeten sich die unordentlicheren Setups
Die andere Seite des Threads war unverblümt: „Mein Setup ist recht einfach" leistete ernsthafte Arbeit. Ein Kommentator sagte, das eigene Upgrade sei alles andere als reibungslos verlaufen. Man verbrachte den größten Teil eines Tages damit, Pre- und Post-Install-Fehlern hinterherzujagen, erlebte beim Booten einen Kernel-Panic und löschte am Ende den Host, um aus Backups wiederherzustellen. Man war fair genug zuzugeben, das sei nicht das Ende der Welt gewesen, und man freue sich, dass der ursprüngliche Poster eine gute Erfahrung gemacht habe — aber die Warnung war klar. Reibungslose Upgrades sind nicht gleich verteilt.
Ein weiterer Nutzer erlebte ebenfalls bei zwei von drei Instanzen einen Kernel-Panic und musste einige GRUB-bezogene Einstellungen ändern, bevor sich alles einpendelte. Jemand anderes hatte ein komplexeres System mit individuellen i915- und xe-Kernelmodulen, HDD- und NVMe-Passthrough per ID sowie weiteren individuellen Anpassungen. Das eigene Upgrade lief nicht ganz so leicht, verlief aber trotzdem besser als erwartet, weil das Tool im Vorfeld auf viele zu behebende Punkte hinwies. Das ist der realistischere Mittelweg: Proxmox erledigte seinen Job, aber lokale Eigenheiten haben trotzdem ein Mitspracherecht.
Container und Hacks waren der Stresstest
LXC entpuppte sich als stille Trennlinie. Der ursprüngliche Poster hatte nur einen Pi-hole-Container, der das Upgrade ohne Konfigurationsänderungen problemlos überstand. Nach dem Neustart startete er normal, und die DNS-Auflösung funktionierte weiter. Man ließ pve8to9 --full danach sogar noch einmal laufen und sah eine Warnung, dass der Cgroup-Support-Status des Containers nicht abgerufen werden konnte, weil das Skript den Pfad zum Systemd-Binary nicht konstruieren konnte. Die eigene Einschätzung war, dass es sich um eine bekannte kosmetische Warnung im Checker auf PVE 9 handelte, nicht um ein tatsächliches Container-Problem.
Ein anderer Kommentator hatte eine deutlich hässlichere Container-Geschichte. Das eigentliche OS-Upgrade sei reibungslos verlaufen, aber ein Haufen früherer Admin-Hacks für Docker und FreeIPA innerhalb von LXC sei danach kaputtgegangen. Zu diesen Hacks gehörte unter anderem, AppArmor aggressiv zu deaktivieren, und das Upgrade-Tool erkannte das meiste davon nicht. Das persönliche Fazit war einfach: Man plane, dieses Setup bald in VMs zu verlagern. Das ist eine nützliche Lektion. Upgrade-Tools können Probleme auf Plattformebene abfangen. Sie können nicht immer Jahre von „mach es einfach zum Laufen"-Entscheidungen verstehen, die sich innerhalb eines Containers aufgetürmt haben.
Die Netzwerk-Gremlins warteten ein paar Tage
Nicht jedes Problem zeigte sich sofort. Ein Nutzer upgradete einen Fünf-Node-Cluster Node für Node von 8.4 auf 9.2.3, und anfangs sah alles gut aus. Nach ein paar Tagen verloren dann einige Nodes die LAN-Verbindung, mit Logs voller Netzwerkfehler. Der schnelle Fix bestand darin, die Verarbeitung von der Netzwerkkarte abzuschalten und auf die CPU zu verlagern. Genau diese Art von verzögertem Ausfall ist der Grund, warum sich erfahrene Admins nach dem ersten erfolgreichen Neustart nicht vollständig entspannen.
Das erklärt auch, warum die Leute immer wieder auf die offizielle Dokumentation und bekannte Upgrade-Probleme verwiesen. Ein Link zum Upgrade-Guide tauchte im Thread auf, gefolgt von der Erinnerung, wirklich alles zu lesen, besonders den Abschnitt zu bekannten Problemen. Das klingt vielleicht selbstverständlich, ist aber genau der Ratschlag, den Leute überspringen, wenn sie sich glücklich fühlen. Der erfolgreiche Weg hier war nicht „YOLO-Dist-Upgrade". Es waren Backups, Checkliste, Doku, Repo-Wechsel, Upgrade, Neustart, Verifizierung — und dann weiter beobachten. Langweilige Schritte. Sehr gute Schritte.
Die Unterstützung des Projekts wurde Teil der Geschichte
Der letzte Schritt des ursprünglichen Posters gab dem Thread seinen emotionalen Höhepunkt: Nach dem reibungslosen Upgrade kaufte man ein einjähriges Community-Abo. Das ist nicht nur Fan-Service. Es ist die Anerkennung, dass ausgereifte Upgrade-Pfade, detaillierte Doku und Preflight-Tools Arbeit sind. Sie entstehen nicht, weil Infrastruktur-Elfen sich gelangweilt haben. Sie werden gepflegt, getestet, diskutiert und verbessert, bis sich ein beängstigender Versionssprung für einen normalen Nutzer mit einem normalen Server routinemäßig anfühlt.
Diese Botschaft traf zusammen mit einer weiteren Migrationsgeschichte ein: Ein Kommentator hatte gerade die erste Proxmox VE installiert, nach dem Wechsel von Microsoft Hyper-V, und mochte es bereits. Das ist der größere Kontext. Proxmox bedient längst nicht mehr nur langjährige Homelab-Nutzer. Es fängt Leute auf, die andere Plattformen verlassen, Leute, die Cluster aufbauen, Leute mit zusammengeflickten Containern, Leute mit individuellen Kerneln, Leute, die Gemini oder Claude um Hilfe bitten, wenn der Boot-Vorgang schiefläuft. Der Upgrade-Pfad muss all diese Leute irgendwo nahe der Realität abholen.
Reibungslos bedeutet nicht sorglos
Die beste Erkenntnis aus dem Thread ist nicht, dass Proxmox 8 auf 9 risikofrei ist. Sie ist, dass Proxmox ein ernstzunehmendes Upgrade für viele Menschen handhabbar gemacht hat. Bei einfachen Standalone-Nodes kann der Weg fast langweilig sein. Bei Clustern kann er trotzdem sauber verlaufen, wenn man der Doku folgt. Bei individualisierten Hosts, alten Hacks, Passthrough, individuellen Modulen und fragilen Containern kann das Upgrade trotzdem zubeißen. Das ist kein Widerspruch. Das ist Infrastruktur.
Die richtige Haltung ist also vorsichtiger Optimismus. Führen Sie pve8to9 --full aus. Lesen Sie den Upgrade-Guide und die bekannten Probleme. Sichern Sie Guests und Host-Konfigurationen. Wissen Sie, wie Sie sich erholen, wenn der Bootloader zickt. Gehen Sie nicht davon aus, dass sich ein Container voller Hacks wie eine saubere VM verhält. Beobachten Sie das System tagelang, nicht minutenlang. Und wenn ein so großes Upgrade reibungslos verläuft, sagen Sie vielleicht Danke mit mehr als nur einem Kommentar. Der beängstigende Teil ist, dass Versionssprünge nie aufhören werden, beängstigend zu sein. Der beeindruckende Teil ist, wenn gute Ingenieursarbeit sie fast ereignislos wirken lässt.