Proxmox VE: Upgrade von Version 8 auf 9

Aus maxTechCorner

Auf einen Blick

Gilt fürUpgrade Proxmox VE 8.4 (Debian 12 „Bookworm“) auf Proxmox VE 9.2 (Debian 13 „Trixie“); Einzelserver und Cluster, optional mit Ceph
BereichServer-Software
DauerVorbereitung ca. 1–2 Stunden, dann ca. 30–90 Minuten je Knoten
Rechteroot auf allen Knoten, Konsole per IPMI/iDRAC/iLO oder SSH mit tmux
StandOktober 2026

Proxmox VE von Version 8 auf 9 upgraden ist seit August 2026 Pflicht, denn Proxmox VE 8 erhält keine Updates mehr. Diese Anleitung zeigt das Upgrade von 8.4 auf die aktuelle 9.2 mit dem Prüfskript pve8to9, die Umstellung der Repositorys von Bookworm auf Trixie im deb822-Format, das Vorgehen im Cluster Knoten für Knoten und die typischen Stolperfallen aus dem offiziellen Upgrade-Leitfaden.

Upgrade von Proxmox VE 8 auf 9: Ausgangsstand 8.4 mit Ceph Squid, getestete Backups, Konsolenzugang und pve8to9 --full ohne Fehler führen zum Upgrade-Lauf. Er stellt die Repositorys auf Trixie im deb822-Format um, führt apt dist-upgrade aus und startet neu; im Cluster folgt Knoten für Knoten mit Live-Migration.

Warum das Upgrade jetzt ansteht

Proxmox VE 9.0 erschien im August 2025 auf Basis von Debian 13 „Trixie“; die aktuelle 9.2 (Mai 2026) bringt Kernel 7.0, QEMU 11.0, ZFS 2.4 und Ceph Tentacle. Proxmox VE 8 hat im August 2026 das Support-Ende erreicht – es gibt keine Sicherheitsupdates mehr, auch nicht im Enterprise-Repository. Ein ungepatchter Hypervisor ist ein erhebliches Risiko, weil er alle Gäste trägt.

Was 9.x unter anderem mitbringt:

  • Snapshots von VMs mit TPM auf dateibasiertem Storage (TPM-Zustand in qcow2), Container aus OCI-Images (Technology Preview).
  • HA-Regeln statt HA-Gruppen, in 9.2 dynamischer Lastausgleich für HA-Gäste und clusterweites disarm/arm für Wartungsarbeiten.
  • SDN-Fabrics (OpenFabric, OSPF, in 9.2 auch WireGuard und BGP).
  • Voraussetzung für einige Funktionen des Proxmox Datacenter Manager.

Voraussetzungen und Prüfung mit pve8to9

Prüfpunkt Anforderung
Ausgangsversion alle Knoten auf aktueller 8.4, pve-manager mindestens 8.4.1 (pveversion)
Ceph (hyperkonvergent) vorher auf Ceph 19.2 Squid aktualisieren; Quincy oder Reef zuerst nach eigener Anleitung anheben
Backups alle VMs und Container gesichert und Rücksicherung getestet
Speicherplatz mindestens 5 GB frei auf /, besser über 10 GB
Zugang Konsole per IPMI/iKVM oder vor Ort; bei SSH in tmux oder screen arbeiten, nicht in der Konsole der Weboberfläche
Cluster Cluster gesund, Quorum vorhanden (pvecm status)
Co-installierter PBS zuerst den Leitfaden für Proxmox Backup Server 3 auf 4 lesen

Zuerst den Stand 8.4 herstellen, dann das Prüfskript mit allen Tests laufen lassen: 

apt update
apt dist-upgrade
pveversion
pve8to9 --full

pve8to9 ändert nichts, es meldet nur. Jede Warnung und jeden Fehler beheben und das Skript erneut ausführen, bis es sauber durchläuft. Häufige Meldungen:

  • LVM-Autoaktivierung: Neue logische Volumes legt Proxmox VE 9 ohne Autoaktivierung an. Für bestehende Gastvolumes – dringend bei gemeinsam genutztem LVM, etwa über ISCSI oder FC – das mitgelieferte Skript ausführen: /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation.
  • systemd-boot-Metapaket: entfernen, wenn pve8to9 dazu rät; nur behalten, wenn systemd-boot bewusst manuell eingerichtet wurde.
  • GRUB im UEFI-Modus auf LVM: fehlendes Paket nachinstallieren, sonst droht ein nicht startendes System:
[ -d /sys/firmware/efi ] && apt install grub-efi-amd64
  • Audit-Meldungen im Journal: vorab systemctl disable --now systemd-journald-audit.socket ausführen.

Upgrade von Proxmox VE 8 auf 9 Schritt für Schritt

Schritt 1: Debian-Quellen auf Trixie umstellen

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
# weitere Dateien in /etc/apt/sources.list.d/ prüfen, Bookworm-Reste auskommentieren
grep -r bookworm /etc/apt/sources.list /etc/apt/sources.list.d/

Schritt 2: Proxmox-Repository im deb822-Format

Ohne Subskription (No-Subscription): 

cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
# alten PVE-8-Eintrag (bookworm pve-no-subscription) aus .list-Dateien entfernen

Mit Subskription stattdessen /etc/apt/sources.list.d/pve-enterprise.sources anlegen (URI https://enterprise.proxmox.com/debian/pve, Suite trixie, Component pve-enterprise, gleicher Signed-By-Eintrag) und nach erfolgreichem apt update die alte pve-enterprise.list löschen.

Schritt 3: Ceph-Repository (nur mit Ceph)

Auch unter Trixie bleibt zunächst Squid installiert; der Wechsel auf Tentacle ist ein eigener, späterer Schritt. 

cat > /etc/apt/sources.list.d/ceph.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/ceph-squid
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
rm /etc/apt/sources.list.d/ceph.list

Mit Subskription lautet die URI https://enterprise.proxmox.com/debian/ceph-squid mit Component enterprise. Meldet apt update einen Fehler 401, hilft pvesubscription update --force.

Schritt 4: Upgrade ausführen

apt update
apt policy | grep trixie     # Quellen kontrollieren
apt dist-upgrade

Der Lauf dauert je nach Platten wenige Minuten bis über eine Stunde. Fragen zu geänderten Konfigurationsdateien beantworten Sie so:

Datei Empfehlung
/etc/issue aktuelle Version behalten
/etc/lvm/lvm.conf Version des Paketbetreuers, sofern nicht selbst angepasst
/etc/ssh/sshd_config Version des Paketbetreuers, sofern nicht selbst angepasst
/etc/default/grub im Zweifel aktuelle Version behalten
/etc/chrony/chrony.conf Version des Paketbetreuers; eigene Server vorher in /etc/chrony/sources.d/ auslagern

Danach pve8to9 erneut ausführen und den Knoten neu starten – auch wenn vorher schon ein neuerer Opt-in-Kernel lief. Kontrolle: pveversion -v und uname -r. Optional wandelt apt modernize-sources verbliebene .list-Dateien ins deb822-Format um (alte Dateien bleiben als .bak erhalten).

Im Cluster: Knoten für Knoten mit Live-Migration

Live-Migration von Proxmox VE 8 nach 9 funktioniert immer, die Gegenrichtung ist nicht unterstützt. Daraus ergibt sich die Reihenfolge:

  1. Ersten Knoten leeren: Gäste per Live-Migration auf die übrigen 8.4-Knoten verschieben. HA-Gäste verschiebt der Wartungsmodus automatisch: ha-manager crm-command node-maintenance enable pve1.
  2. Bei Ceph vor dem Neustart ceph osd set noout setzen, damit nicht unnötig umverteilt wird.
  3. Knoten wie oben aktualisieren, neu starten, Wartungsmodus mit … disable pve1 beenden und prüfen (pvecm status, ceph -s).
  4. Gäste des nächsten Knotens auf den bereits aktualisierten Knoten migrieren, dann diesen Knoten aktualisieren – und so weiter.
  5. Nach dem letzten Knoten ceph osd unset noout.

Weitere Punkte im gemischten Betrieb:

  • Eine Weboberfläche auf einem 9er-Knoten kann bei Aktionen auf einem 8er-Knoten Ungereimtheiten zeigen; dann die Oberfläche des jeweiligen Knotens nutzen.
  • HA-Gruppen werden zu HA-Regeln, sobald alle Knoten auf Version 9 laufen. Probleme zeigt journalctl -eu pve-ha-crm auf dem aktiven CRM-Knoten.
  • Gemischte CPU-Modelle oder -Hersteller können nach der Live-Migration zu hängenden VMs führen. Vorher mit einer unkritischen VM testen; Grundlagen in Proxmox VE: Cluster und Hochverfügbarkeit.
  • Ceph meldet nach dem Neustart des ersten Monitors eventuell HEALTH_ERR wegen unsicherer Schlüsseltypen. Die Dienste laufen weiter; die Schlüssel werden nach dem Upgrade aller Knoten laut Admin-Handbuch migriert.

Typische Stolperfallen

Thema Auswirkung Abhilfe
/etc/sysctl.conf wird unter Trixie nicht mehr gelesen Einstellungen nach /etc/sysctl.d/<NN>-<name>.conf verschieben (auch den rp_filter-Override für EVPN-Exit-Nodes)
/tmp ist jetzt tmpfs (bis 50 % RAM), Dateien in /tmp und /var/tmp werden im Betrieb aufgeräumt keine dauerhaften Daten dort ablegen
Netzwerk-Schnittstellennamen können sich durch den neuen Kernel ändern, Bridge ohne Uplink vorab mit pve-network-interface-pinning feste Namen vergeben, Konsolenzugang bereithalten
Container mit sehr altem systemd cgroup v1 entfällt, systemd 230 und älter läuft nicht mehr alte Container vorher aktualisieren oder ersetzen
Speicher-Plugins von Drittanbietern funktionieren ggf. nicht auf eine für Version 9 freigegebene Plugin-Version warten
Backup-Software von Drittanbietern teils Probleme mit QEMU-Maschinenversion 10.0 und neuer Freigabe des Herstellers prüfen, betroffene VMs bei Bedarf auf ältere Maschinenversion festlegen
NVIDIA vGPU ältere Treiber inkompatibel vor dem Upgrade GRID 18.3 oder neuer installieren
PCIe-Passthrough einzelne VMs starten nicht älteren Kernel festlegen, Ursache klären
LVM-Thin-Pool Meldung „Manual repair required“ lvconvert --repair pve/data
Speicheranzeige der VMs Werte über 100 % nur Anzeige: Der Overhead der VM wird jetzt mitgezählt
Ceph-Full-Mesh mit FRR Knoten hängt beim Start post-up-Zeile laut Upgrade-Leitfaden anpassen

Bricht das Upgrade ab, die Trixie-Quellen prüfen und mit apt -f install fortsetzen. Fragt apt nach dem Entfernen des Metapakets proxmox-ve, abbrechen – dann fehlt meist eine Paketquelle.

Nach dem Upgrade

  • Ceph Tentacle: Für Neuinstallationen ist Tentacle (20.2) Standard. Bestehende Cluster können auf Squid bleiben und später nach eigener Anleitung wechseln – nicht im selben Wartungsfenster.
  • Proxmox Backup Server: Läuft PBS separat, wird er eigenständig von 3 auf 4 aktualisiert (offizieller Leitfaden „Upgrade from 3 to 4“). PVE 9 sichert auch auf PBS 3, die Aktualisierung sollte aber zeitnah folgen, siehe Proxmox Backup Server: Einrichtung und Backup-Strategie.
  • Backups prüfen: Den nächsten Backup-Lauf und die Benachrichtigungen kontrollieren.
  • Neue Funktionen: HA-Regeln, SDN-Fabrics und eigene CPU-Modelle schrittweise einführen, nicht alles im Upgrade-Fenster.

Hinweise

  • Testlauf: Wer keine Testumgebung hat, installiert Proxmox VE 8.4 in einer VM, stellt die wichtigsten Konfigurationen nach und übt das Upgrade dort – inklusive pve8to9 --full.
  • Wartungsfenster: Pro Knoten mit Neustart und Kontrollen mindestens eine Stunde einplanen; bei Ceph zwischen den Knoten warten, bis ceph -s wieder HEALTH_OK meldet.
  • Zeitdruck: Systeme ohne Updates seit August 2026 haben Vorrang vor neuen Projekten.
  • Bei Upgrade und Betrieb Ihrer Debian- und Proxmox-Server unterstützt Sie das Linux-Consulting von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „https://techcorner.max-it.de/index.php?title=Proxmox_VE:_Upgrade_von_Version_8_auf_9&oldid=5544“