Proxmox 8.2.7 auf 9.2 Upgrade: 6 Nodes und ein PBS

Die Frage, die sich vorsichtige Admins vor dem Start stellen

Der Beitrag war kurz, traf aber genau den Nerv, der Upgrades von Infrastruktur so heikel macht: Kann man direkt von Proxmox 8.2.7 auf 9.2 aktualisieren, und sollte man das tun? Der Fragesteller wollte nicht wissen, ob man einfach auf den Knopf drücken kann oder ob apt das technisch zulässt. Die eigentliche Frage war, ob es klug ist, ein Setup mit sechs Nodes zu nehmen, alle VMs von einer Maschine wegzumigrieren, diesen Node zu aktualisieren, das Ganze Node für Node zu wiederholen, bis der gesamte Cluster auf 9.2 läuft, und erst danach den Proxmox Backup Server nach den Hypervisoren zu aktualisieren.

Diese Vorsicht ist berechtigt und hat nichts mit übertriebener Ängstlichkeit zu tun. Ein Upgrade auf einem einzelnen Node im Homelab ist eine Sache, eine Umgebung aus sechs Maschinen eine völlig andere. Selbst wenn es sich nicht um ein riesiges Rechenzentrum eines Konzerns handelt, existieren feste Abläufe, Abhängigkeiten und Konsequenzen. Die VMs müssen irgendwohin ausweichen können, der Cluster muss stabil bleiben, Storage und Netzwerk müssen weiter funktionieren und der Backup-Server muss verlässlich bleiben. Dahinter steht die unbequeme Tatsache, dass ein Major-Version-Upgrade selten nur das Paket selbst betrifft. Es zieht Debian, den Kernel, QEMU, Maschinentypen, Paket-Repositories, Systemprüfungen und jede ungewöhnliche lokale Konfiguration mit sich, die jahrelang unbemerkt ihren Dienst getan hat.

Die Antwort im Diskussionsfaden war fast schon nüchtern: Aktualisieren Sie zuerst auf das neueste Proxmox 8, wahrscheinlich Version 8.4, und folgen Sie danach exakt der offiziellen Anleitung für das Upgrade von 8 auf 9. Genau diesen Tonfall schätzen Admins: ohne Drama, ohne Abkürzungen und ohne magische Patentrezepte. Lesen Sie die Dokumentation, lassen Sie den Checker laufen, beheben Sie die gemeldeten Probleme, führen Sie ihn erneut aus und starten Sie den Vorgang erst, wenn die Maschine sauber vorbereitet ist.

„Zuerst auf das neueste 8 aktualisieren“ wurde zum Konsens

Der deutlichste Rat lautete, Proxmox 8.2.7 nicht als direkte Absprungbasis zu nutzen. Mehrere Teilnehmer betonten denselben Punkt: Zuerst auf den aktuellsten 8.x-Stand aktualisieren und von dort aus auf das neueste 9.x migrieren. Eine Antwort brachte die Versionsbedenken auf den Punkt: Wenn Sie auf die nächste Hauptversion wechseln, wählen Sie ohnehin keinen veralteten Zwischenstand wie 9.0. Sie erhalten die aktuelle Release 9. Praktisch gesehen ist das Ziel also 9.2, doch der sicherere Weg führt über einen vollständig aktualisierten Stand des 8er-Zweigs.

Dieser Rat ist wichtig, weil Zwischenversionen häufig Upgrade-Helfer, Kompatibilitätskorrekturen, Warnhinweise und angepasste Repository-Konfigurationen mitbringen, die älteren Releases fehlen. Es geht darum, Unbekannte zu minimieren. Wenn der dokumentierte Pfad voraussetzt, dass Sie auf dem neuesten Stand von 8.x stehen, bevor Sie zu 9.x wechseln, bringt ein Sprung von einem älteren 8.2.7-Host nur zusätzliche Risiken ohne jeden Vorteil. Je unspektakulärer die Ausgangsbasis ist, desto weniger Überraschungen treten auf.

Ein Nutzer fasste die praxiserprobte Vorgehensweise zusammen: Befolgen Sie die Upgrade-Anleitung präzise und weichen Sie nicht davon ab. Führen Sie die Prüfung aus, beheben Sie die Hinweise, prüfen Sie erneut und wiederholen Sie das, bis alle Warnungen und Fehler behoben oder verstanden sind. Der Nutzer berichtete, dass er 10 Server ohne Probleme aktualisiert habe, die nicht selbstverschuldet gewesen wären. Diesen Satz sollte man sich merken. Ein Major-Upgrade bringt genug Risiken mit sich, daher sollte man jede eigene Fehlerquelle ausschließen, bevor apt den Punkt erreicht, an dem es kein Zurück mehr gibt.

Der Link zur Anleitung war Antwort und Haltungstest zugleich

Die am höchsten bewertete direkte Antwort war schlicht ein Link zur Anleitung für das Proxmox-Upgrade von 8 auf 9. Ein anderer Kommentator ergänzte: „Mehr brauchen Sie nicht. Thread beendet.“ Das klingt schroff, spiegelt aber die Kultur im Infrastrukturbereich wider. Man muss das Handbuch nicht in einem Forum neu schreiben, wenn es bereits existiert. Bei einem großen Hypervisor-Upgrade dient die offizielle Anleitung als verbindliche Karte.

Das ist ernüchternd, aber ehrlich. Die Kurzfassung lautet: Auf den neuesten Stand 8.4 aktualisieren, pve8to9 --full ausführen, alle relevanten Punkte abarbeiten und danach das Upgrade auf 9.2 Node für Node durchführen. Dieser einzelne Satz allein schützt Ihren Cluster jedoch noch nicht. Die ausführliche Dokumentation existiert wegen der vielen Details: Repositories, Ceph (falls im Einsatz), Gastkompatibilität, veraltete Maschinentypen, Netzwerk-Schnittstellennamen, gehaltene Pakete, Cluster-Integrität und Backup-Bereitschaft. Die Diskussion zeigte deutlich: „Kann ich das?“ ist eine rein technische Frage, „Sollte ich das tun?“ dagegen eine organisatorische.

Der Fragesteller dachte bereits strukturiert, indem er plante, die Knoten nacheinander zu leeren. Das ist genau das richtige Vorgehen. Die Community ergänzte diesen Plan um einen wesentlichen Punkt: Neben dem Migrationskonzept braucht es immer eine Schleife zur Validierung.

Der Rolling-Node-Plan ist sinnvoll, birgt aber weiterhin Risiken

Alle VMs von einem Node wegzumigrieren, diesen Node zu aktualisieren, ihn zu testen und erst dann zum nächsten überzugehen, ist ein solides Konzept. Es begrenzt den Fehlerbereich und hält die Workloads am Laufen. So lassen sich maschinenspezifische Probleme erkennen, bevor alle sechs Server auf dem neuen Stand sind. Wenn der erste aktualisierte Node Probleme macht, stoppt man den Vorgang, anstatt stur weiterzumachen, nur weil der Kalender heute Upgrade-Tag vorsieht.

Ein rollierendes Upgrade erzeugt jedoch eigene Anforderungen. Für eine gewisse Zeit befindet sich der Cluster in einem Mischbetrieb verschiedener Versionen. Das ist nicht per se verboten, aber ein klarer Grund, besonnen zu handeln und diesen Zustand nicht unnötig in die Länge zu ziehen. Jeder Node muss vor dem Eingriff sauber und geleert sein, kontrolliert aktualisiert, bewusst neu gestartet und getestet werden, bevor VMs zurückkehren. Danach wiederholt man denselben Ablauf, ohne spontane Abweichungen oder die Annahme, der nächste Node sei identisch. Cluster bestrafen Annahmen schnell.

Der ursprüngliche Plan enthielt zudem die Frage nach der Reihenfolge: Zuerst alle sechs PVE-Nodes aktualisieren, danach die eine PBS-Instanz. Das ist machbar, verlangt aber eine Grundregel: Starten Sie niemals ohne geprüfte Backups. Aussagen wie „Die Jobs laufen meist durch“ oder „Das Dashboard ist grün“ genügen nicht. Sie müssen sicher wissen, welche Systeme Sie im Ernstfall wohin wiederherstellen können, falls das Upgrade eines Nodes fehlschlägt. Der Proxmox Backup Server ist Teil des Sicherheitsnetzes, und dieses Netz darf keine Nebensache sein, auch wenn sein eigenes Upgrade erst am Ende ansteht.

Ein rollierendes Vorgehen hat die richtige Struktur. Der Fehler liegt darin, eine gute Struktur mit einer Erfolgsgarantie zu verwechseln. Es bleibt ein großes Upgrade, das ein Wartungsfenster, Konsolenzugriff, Notizen und einen Rückfallplan erfordert.

Erfolgsberichte mit alter Hardware halfen, aber nur bedingt

Ein Nutzer berichtete, er habe ältere Server aus der Ära um 2010 problemlos von der neuesten Version 8.x auf 9.x aktualisiert, und auf diesen Systemen lief sogar ein Kernel der Version 7.0.x. Das klingt ermutigend, da man bei betagter Hardware oft die seltsamsten Fehlerbilder befürchtet. Ein anderer Kommentator fragte gezielt nach einem HP DL380 G7 und Hardware-Passthrough, um die Erfahrungen anderer auf sein eigenes Risiko zu übertragen. Die Konfiguration passte jedoch nicht exakt: Im Erfolgsfall handelte es sich um Dell-Systeme R610 und R710 mit Xeon-X5650-CPUs, und Passthrough war auf diesem Host nicht aktiv.

Dieser Austausch zeigt gut, wie Erfahrungsberichte bei Upgrades zu bewerten sind. Erfolge anderer sind nützlich, aber nur bis zu einer gewissen Grenze. Das gleiche Baujahr garantiert nicht die gleiche Hardware, und der gleiche Kernel bedeutet nicht das gleiche Passthrough-Verhalten. Dieselbe Servermarke garantiert weder identische Firmware noch gleiche Storage-Controller, Netzwerkkarten, BIOS-Einstellungen oder IOMMU-Gruppen. Es beruhigt zwar, wenn alte Hardware ein neues Release übersteht, garantiert für Ihre konkrete Maschine aber nichts.

Die bessere Frage an die Hardware lautet nicht: „Hat das bei jemandem funktioniert?“, sondern: „Welcher Teil meines Setups weicht vom Standard ab?“ PCIe-Passthrough ist speziell. Sehr alte RAID-Controller können Probleme bereiten, ebenso wie Treiber außerhalb des Kernels, angepasste Netzwerkkonfigurationen und veraltete VM-Maschinentypen. Ein Nutzer warnte davor, dass bestimmte alte Maschinenmodelle in Proxmox 9 nicht mehr unterstützt werden und eine Änderung dieser Typen sogar Softwarelizenzen in den Gastsystemen ungültig machen kann. Das sind Details, die ein reibungsloses Host-Upgrade schnell zu einem Problem auf Gastebene machen.

Der Erfolgsbericht mit den alten Servern ist also eine gute Nachricht. Er erlaubt Optimismus bei der Vorbereitung, rechtfertigt aber keine Nachlässigkeit.

Selbstverschuldete Ausfälle sind das eigentliche Risiko

Der treffendste Satz in der Diskussion war jener über selbstverschuldete Probleme, denn dort liegen die typischen Stolperfallen. Proxmox ist nicht außergewöhnlich riskant und 9.2 nicht fehlerbehaftet. Typische Fehler entstehen, wenn Admins Warnungen übergehen, Paketquellen ungeprüft lassen, zurückgehaltene Pakete vergessen, alte Konfigurationen ignorieren oder ein Upgrade über SSH starten, ohne eine alternative Konsole bereit zu haben, und sich dann wundern, wenn das Netzwerk weg ist.

Die Lösung liegt in sorgfältigem Arbeiten, nicht in Panik. Bringen Sie jeden 8.2.7-Knoten zuerst auf den neuesten 8.x-Stand und prüfen Sie den Clusterzustand. Leeren Sie den Node und lassen Sie den Upgrade-Checker mit vollständiger Ausgabe laufen. Lesen Sie die Hinweise aufmerksam, beheben Sie die genannten Punkte und wiederholen Sie die Prüfung. Verifizieren Sie Backups und den Zugriff per Out-of-Band-Konsole. Klären Sie ab, ob alte VM-Maschinentypen, Passthrough-Geräte, Storage-Pfade und Netzwerkeinstellungen betroffen sind. Erst dann aktualisieren, prüfen und zum nächsten System übergehen.

Dieser Ablauf mag langsam wirken, ist im Vergleich zur Fehlersuche in einem beschädigten Cluster bei stehenden VMs jedoch schnell. Die Verfügbarkeit während des rollierenden Upgrades ist nur ein Vorteil: Ebenso wichtig ist die Möglichkeit, nach dem ersten Node anzuhalten, falls die Praxis vom Plan abweicht.

Die Community gab im Grunde drei Antworten gleichzeitig. Die optimistische Seite bestätigte, dass das Vorgehen funktioniert. Die vorsichtige Seite riet, zuerst auf die neueste Version 8 zu gehen und die Dokumentation exakt zu befolgen. Die ungeduldige Seite verwies direkt auf das Handbuch. Alle drei meinen dasselbe: Der Schritt von Proxmox 8.2.7 auf 9.2 ist kein unmöglicher Sprung, aber ein Weg, den man Schritt für Schritt gehen muss.

Das beste Upgrade ist jenes, das fast schon lästig minutiös geplant wirkt

Diese Frage taucht regelmäßig auf, weil jede Administration früher oder später vor dieser Entscheidung steht. Irgendwann ist die vertraute Version in die Jahre gekommen und die neue stabil genug, aber noch frisch. Der Cluster ist zu wichtig für Experimente, aber nicht so groß, dass ein eigenes Projektteam bereitsteht. Also übernimmt man die Aufgabe selbst: VMs migrieren, Dokumentation lesen, Checks ausführen und hoffen, dass der erste Node völlig unspektakulär wieder hochfährt.

Genau das macht den Wechsel auf Proxmox 9.2 aus. Die Software mag bereit sein, aber die Einsatzbereitschaft entscheidet sich vor Ort. Sie hängt von den Nodes, den Gästen, der Hardware, den Backups, der Toleranz für Ausfallzeiten und der Geduld bei der Umsetzung ab. Bei sechs Nodes führt Wiederholung zum Erfolg: derselbe Ablauf auf jedem System, keine Abkürzungen beim zweiten oder dritten Host und keine Entwarnung, bevor der letzte Gast sauber läuft und der PBS zuverlässig arbeitet.

Der Weg von 8.2.7 auf 9.2 ist machbar. Der sicherste Pfad führt von 8.2.7 auf das neueste 8.x, gefolgt von Prüfung, Bereinigung und dem schrittweisen Upgrade auf 9.2 Node für Node. Wer in der Diskussion am souveränsten wirkte, versprach keine Zaubertricks, sondern empfahl schlicht, die Anleitung zu befolgen, den Checker zu nutzen, Warnungen zu beheben und alles andere als vermeidbares Risiko zu betrachten.

Das ist keine spektakuläre Antwort, aber genau diejenige, die den Betrieb stabil hält.