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 berührt 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 über Ihren Cluster

Der wichtigste Befehl vor jedem Major-Upgrade ist der Kompatibilitäts-Checker. Für den Weg von 8.x auf 9.x heißt er pve8to9 und ist Teil des Pakets pve-manager. Ausführen müssen 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-Einträge, die noch auf bullseye/bookworm zeigen
• Zertifikate, die in Kürze ablaufen
• Nicht mehr unterstützte CPU-Flags (relevant bei sehr alter Hardware)

Warnungen sind ernst zu nehmen. In unseren Projekten sehen wir typischerweise zwei bis fünf 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 Gäste. Bei kritischen VMs zusätzlich einen ZFS- oder Ceph-Snapshot direkt vor dem Node-Reboot.

Wer keinen Proxmox Backup Server im Einsatz hat, sollte spätestens jetzt über eine PBS-Instanz nachdenken — für 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 für Node, niemals parallel

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

Schritt	Aktion	Warum
1	Ersten Node auswählen (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 prüfen — Quorum wiederhergestellt?	Cluster gesund
8	Nächsten 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 während des Upgrade-Fensters unterstützt, nicht als Dauerzustand.

Quorum und HA: die kritische halbe Stunde

Ein 3-Node-Cluster verträgt genau einen Ausfall. Während ein Node im Reboot ist, sind Sie also auf exakt zwei verbleibende Nodes angewiesen — eine dieser beiden fällt jetzt aus, verliert der Cluster das Quorum, und pmxcfs wird read-only.

Zwei konkrete Maßnahmen reduzieren das Risiko drastisch:

• Redundanter Corosync-Ring: Wir konfigurieren immer zwei physisch getrennte Netze für Corosync (z.B. dediziertes VLAN plus Management-Netz als Fallback). Wenn ein Switch neu startet, überlebt Corosync über den zweiten Ring.
• HA-Groups sauber setzen: VMs, die zwingend online bleiben müssen, bekommen eine HA-Group mit restricted=1 und mindestens zwei Failover-Nodes. Während des Upgrades verschieben wir die primäre Priorität weg vom zu aktualisierenden Node.

Für 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 läuft 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 hängen.

Unsere Rollback-Optionen — in dieser Reihenfolge:

1. Kernel-Downgrade via GRUB: Der alte Kernel bleibt bei apt dist-upgrade erhalten. Beim Boot über das GRUB-Menü den vorherigen Kernel wählen und prüfen, ob der Node wieder normal läuft. Löst oft Treiber- und NIC-Probleme.
2. Paket-Downgrade: Für einzelne kaputte Pakete kann apt install <paket>=<alte-version> helfen — sofern der APT-Cache noch die alten Versionen enthält. 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-Änderungen), 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 übernimmt 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 grundsätzlich tun:

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

Nach dem Upgrade: aufräumen 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 prüfen und ggf. ältere Versionen entfernen (aber immer mindestens den vorletzten behalten)
• Snapshots (rpool@pre-pve9-upgrade) nach zwei Wochen fehlerfreiem Betrieb löschen — vorher nicht

Und dokumentieren Sie die tatsächlich durchlaufenen Schritte, die Zeitfenster und die Auffälligkeiten. Beim nächsten Major-Upgrade — typischerweise in zwei bis drei Jahren — werden Sie für jede Zeile dankbar sein.

---

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