Proxmox Cluster: Major-Upgrade ohne Angst

Ein Major-Upgrade eines Proxmox-Clusters — typischerweise von 8.x auf 9.x — ist der Moment, in dem Administratoren ins Schwitzen kommen. Anders als ein Minor-Update auf einem Einzelserver beruehrt das Major-Upgrade den Corosync-Stack, das Kernel-ABI, das Storage-Plugin-Layout und im schlimmsten Fall die Cluster-Konfigurationsdatenbank pmxcfs. Wer hier ohne Plan startet, riskiert einen geteilten Cluster, verlorene HA-Ressourcen oder VMs, die nach dem Reboot nicht mehr booten.

Die gute Nachricht: Proxmox liefert seit Jahren ein sehr belastbares Upgrade-Werkzeug mit — pve8to9 (bzw. das jeweils passende Skript der Version) — und die Reihenfolge der Schritte ist im Kern seit PVE 5.x gleich geblieben. Dieser Artikel ist unser Playbook aus realen Kundenprojekten: Vorbereitung, Reihenfolge, Quorum-Handling, HA-Verhalten und — wichtig — der Rollback-Pfad, falls es doch klemmt.

Vor dem Upgrade: pve8to9 und die Wahrheit ueber Ihren Cluster

Der wichtigste Befehl vor jedem Major-Upgrade ist der Kompatibilitaets-Checker. Fuer den Weg von 8.x auf 9.x heisst er pve8to9 und ist Teil des Pakets pve-manager. Ausfuehren muessen Sie ihn auf jedem Node einzeln, nicht nur auf einem:

# Auf jedem Node:
apt update && apt dist-upgrade -y   # zuerst die 8er-Reihe vollstaendig aktuell
pve8to9 --full

Der Checker meldet unter anderem:

• Veraltete Storage-Konfigurationen (z.B. LVM-thin ohne discard-Option)
• Kernel-Module, die in 9.x entfernt wurden (etwa alte Broadcom-Treiber)
• Corosync-Konfigurationen mit nur einem Ring
• Repository-Eintraege, die noch auf bullseye/bookworm zeigen
• Zertifikate, die in Kuerze ablaufen
• Nicht mehr unterstuetzte CPU-Flags (relevant bei sehr alter Hardware)

Warnungen sind ernst zu nehmen. In unseren Projekten sehen wir typischerweise zwei bis fuenf Findings pro Cluster — meist harmlos, gelegentlich aber ein echter Show-Stopper wie ein noch nicht migriertes Ceph-Cluster oder ein ZFS-Pool mit deaktivierten Features, die in der neuen Version Default sind.

Snapshot- und Backup-Strategie: die zwei Ebenen

Vor dem Upgrade sichern wir auf zwei Ebenen ab:

1. Config-Backup des Hosts: /etc/pve, /etc/network/interfaces, /etc/corosync/corosync.conf, /etc/hosts, ZFS-Pool-Konfiguration und die Ausgabe von pveversion -v gehen als tar-Archiv auf einen externen Speicher.
2. VM-/CT-Ebene: Ein frischer, konsistenter Proxmox-Backup-Server-Job auf alle Gaeste. Bei kritischen VMs zusaetzlich einen ZFS- oder Ceph-Snapshot direkt vor dem Node-Reboot.

Wer keinen Proxmox Backup Server im Einsatz hat, sollte spaetestens jetzt ueber eine PBS-Instanz nachdenken — fuer ein Major-Upgrade ist “vzdump auf NFS” die absolute Untergrenze. Ein Snapshot alleine ist kein Backup, denn er lebt auf dem Storage, den Sie gerade umbauen.

Reihenfolge der Operationen: Node fuer Node, niemals parallel

Ein Proxmox-Cluster wird rollierend aktualisiert. Nie parallel, nie im Big-Bang. Die bewaehrte Reihenfolge lautet:

Schritt	Aktion	Warum
1	Ersten Node auswaehlen (idealerweise der mit den wenigsten VMs)	Minimale Migration
2	VMs/CTs live auf andere Nodes migrieren	Downtime-frei
3	HA-Ressourcen des Nodes auf “ignored” oder anderen Node fixieren	Verhindert Fence
4	Repositories auf 9.x umstellen	sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list
5	apt update && apt dist-upgrade	Kernpaket-Upgrade
6	Reboot in den neuen Kernel	Neue Kernel-Module aktiv
7	pvecm status pruefen — Quorum wiederhergestellt?	Cluster gesund
8	Naechsten Node — gleicher Ablauf

Erst wenn alle Nodes auf 9.x laufen, aktivieren Sie neue Features wie ein aktualisiertes Corosync-Protokoll oder neue Storage-Optionen. Ein gemischter Cluster (einige Nodes 8.x, einige 9.x) ist offiziell nur waehrend des Upgrade-Fensters unterstuetzt, nicht als Dauerzustand.

Quorum und HA: die kritische halbe Stunde

Ein 3-Node-Cluster vertraegt genau einen Ausfall. Waehrend ein Node im Reboot ist, sind Sie also auf exakt zwei verbleibende Nodes angewiesen — eine dieser beiden faellt jetzt aus, verliert der Cluster das Quorum, und pmxcfs wird read-only.

Zwei konkrete Massnahmen reduzieren das Risiko drastisch:

• Redundanter Corosync-Ring: Wir konfigurieren immer zwei physisch getrennte Netze fuer Corosync (z.B. dediziertes VLAN plus Management-Netz als Fallback). Wenn ein Switch neu startet, ueberlebt Corosync ueber den zweiten Ring.
• HA-Groups sauber setzen: VMs, die zwingend online bleiben muessen, bekommen eine HA-Group mit restricted=1 und mindestens zwei Failover-Nodes. Waehrend des Upgrades verschieben wir die primaere Prioritaet weg vom zu aktualisierenden Node.

Fuer Cluster mit vielen HA-VMs empfiehlt sich der Wartungsmodus, den PVE seit 8.1 kennt:

# Node in Wartungsmodus versetzen -- HA migriert automatisch weg
ha-manager crm-command node-maintenance enable pve-node-01

# Nach dem Reboot wieder aktivieren
ha-manager crm-command node-maintenance disable pve-node-01

Bei Zwei-Node-Setups (die es leider auch gibt) ist ein QDevice als externes Quorum-Zeugnis Pflicht. Ohne QDevice bedeutet jedes Upgrade eines Nodes einen kompletten Cluster-Ausfall, weil das Quorum verloren geht.

Der Rollback-Pfad: wenn es doch klemmt

Ehrlich: In neun von zehn Projekten laeuft das Upgrade sauber durch. Der zehnte Fall entscheidet aber, ob Sie um 22 Uhr nach Hause gehen oder um 4 Uhr morgens noch am Konsolen-Kabel haengen.

Unsere Rollback-Optionen — in dieser Reihenfolge:

1. Kernel-Downgrade via GRUB: Der alte Kernel bleibt bei apt dist-upgrade erhalten. Beim Boot ueber das GRUB-Menue den vorherigen Kernel waehlen und pruefen, ob der Node wieder normal laeuft. Loest oft Treiber- und NIC-Probleme.
2. Paket-Downgrade: Fuer einzelne kaputte Pakete kann apt install <paket>=<alte-version> helfen — sofern der APT-Cache noch die alten Versionen enthaelt. Wir cachen deshalb /var/cache/apt/archives vor dem Upgrade extern.
3. PBS-Restore der VMs: Wenn eine VM nach dem Upgrade nicht mehr startet (z.B. wegen QEMU-Machine-Version-Aenderungen), stellen wir sie aus dem PBS-Backup wieder her — notfalls auf einem noch nicht aktualisierten Node.
4. Kompletter Node-Reinstall: Der Node wird aus dem Cluster entfernt (pvecm delnode), frisch mit der alten 8.x-Version installiert und wieder gejoined. Dank pmxcfs uebernimmt er automatisch die Cluster-Konfiguration.

Wichtig: Ein zfs rollback des Root-Pools funktioniert nur, wenn Sie vor dem apt dist-upgrade einen Snapshot des rpool angelegt haben — was wir grundsaetzlich tun:

zfs snapshot -r rpool@pre-pve9-upgrade
# ... Upgrade laeuft schief ...
zfs rollback -r rpool@pre-pve9-upgrade
reboot

Nach dem Upgrade: aufraeumen und dokumentieren

Sobald alle Nodes auf 9.x laufen, gehen wir noch einmal durch:

• pveversion -v auf jedem Node — alle identisch?
• pvecm status — Quorum, Corosync-Ringe, Node-Count stimmen?
• ceph -s (falls Ceph im Einsatz) — alle OSDs up, PGs active+clean?
• Alte Kernel via proxmox-boot-tool kernel list pruefen und ggf. aeltere Versionen entfernen (aber immer mindestens den vorletzten behalten)
• Snapshots (rpool@pre-pve9-upgrade) nach zwei Wochen fehlerfreiem Betrieb loeschen — vorher nicht

Und dokumentieren Sie die tatsaechlich durchlaufenen Schritte, die Zeitfenster und die Auffaelligkeiten. Beim naechsten Major-Upgrade — typischerweise in zwei bis drei Jahren — werden Sie fuer jede Zeile dankbar sein.

---

DATAZONE unterstuetzt Sie beim Proxmox-Major-Upgrade. Wir planen mit Ihnen das Wartungsfenster, fahren den pve8to9-Check auf Ihrem Cluster, buegeln Findings aus und begleiten das Rolling-Upgrade — remote oder vor Ort in Neuburg und Umgebung. Sprechen Sie uns fuer eine unverbindliche Proxmox-Beratung oder ein Upgrade-Angebot einfach an: Kontakt aufnehmen.