Proxmox Management & Wartung durch WZ-IT? Wir prüfen die Ausgangslage und planen das Upgrade auf PVE 9 einschließlich der vorhandenen Abhängigkeiten zu Ceph, PBS und HA. Die laufende Proxmox-Wartung kostet ab 179,90 € netto je Node und Monat; Major-Upgrades wie PVE 8 auf 9 werden als eigener Umfang vorab bestätigt. Jetzt kostenlosen Termin vereinbaren
Proxmox VE 8: Support-Ende im August 2026
Proxmox VE 8 hat im August 2026 das End of Life erreicht (Support-Lifecycle). Seitdem liefert Proxmox für PVE 8 keine Sicherheitsupdates, keine Bugfixes und keinen Support mehr; das betrifft Kernel, QEMU, LXC und alle Proxmox-eigenen Pakete. Die Debian-12-Basis („Bookworm“) erhält über Debian LTS zwar noch bis 30. Juni 2028 Sicherheitsupdates (Debian-Ankündigung), die Proxmox-Schicht darüber bleibt aber ungepatcht. Wer produktive Workloads noch auf PVE 8 betreibt, sollte das Upgrade deshalb sofort einplanen (Stand Oktober 2026).
Dieser Guide führt Schritt für Schritt durch das Upgrade auf Proxmox VE 9 (Debian 13 „Trixie") - mit besonderem Fokus auf Enterprise-Setups mit Ceph-Clustern, Proxmox Backup Server und High Availability.
Inhaltsverzeichnis
- Proxmox VE 8: Support-Ende im August 2026
- Was ist neu in Proxmox 9? Unterschiede zu PVE 8
- Voraussetzungen prüfen
- Schritt 1: PVE 8.4.1 sicherstellen
- Schritt 2: Backups erstellen
- Schritt 3: Upgrade-Check mit pve8to9 ausführen
- Schritt 4: Ceph auf Squid upgraden
- Schritt 5: PBS auf Version 4 upgraden
- Schritt 6: APT-Repositories umstellen
- Schritt 7: Upgrade ausführen
- Schritt 8: Post-Upgrade Checks
- Cluster-Upgrade-Strategie
- Typische Fehler und wie man sie vermeidet
- Unser Vorgehen bei WZ-IT
Was ist neu in Proxmox 9? Unterschiede zu PVE 8
Proxmox VE 9.0 wurde am 5. August 2025 veröffentlicht. Die aktuelle Version ist PVE 9.2 vom 21. Mai 2026 (Roadmap). Die wichtigsten Neuerungen der 9er-Reihe und des aktuellen Releases gegenüber PVE 8:
Infrastruktur-Basis:
- Debian 13.5 „Trixie" als Unterbau (PVE 8: Debian 12 „Bookworm")
- Linux Kernel 7.0
- QEMU 11 und ZFS 2.4
Enterprise-Features:
- Dynamischer Load Balancer: Der Cluster Resource Scheduler berücksichtigt die aktuelle Auslastung bei der Platzierung HA-verwalteter Gäste
- HA Arm/Disarm: Der HA-Stack lässt sich für geplante Arbeiten kontrolliert aussetzen und wieder aktivieren
- WireGuard- und BGP-Fabrics: Neue SDN-Fabric-Protokolle und feinere Filter für BGP und EVPN
- Eigene CPU-Modelle: CPU-Profile und unterstützte Flags lassen sich zentral in der Oberfläche verwalten und prüfen
- HA-Rules statt HA-Groups: Flexiblere Resource-to-Node- und Resource-to-Resource-Affinitäten aus PVE 9.0
- OCI-Container in LXC: OCI-Images lassen sich seit PVE 9.1 als LXC-Templates verwenden; die Funktion bleibt für passende Workloads einzuordnen
Voraussetzungen prüfen
Bevor Sie anfangen, diese Checkliste durchgehen:
| Anforderung | Details |
|---|---|
| PVE Version | Mindestens 8.4.1 auf allen Nodes |
| Freier Speicher | Min. 5 GB auf Root-Partition (10 GB+ empfohlen) |
| Ceph | Muss zuerst auf 19.2 Squid upgraded werden |
| PBS | Auf dem Node mitinstalliert: nach der Anleitung PBS 3 auf 4 mitziehen; separater PBS-Host: idealerweise vorab auf Version 4 |
| Container-OS | CentOS 7, Ubuntu 16.04 (systemd ≤230) werden nicht mehr unterstützt |
| Backups | Vollständiges Backup aller VMs/CTs vor dem Upgrade |
| Zugang | Stabile Verbindung, kein Upgrade über instabiles WLAN/VPN. Physische Konsole oder unabhängige Managementkonsole wie IPMI/iKVM verwenden; bei SSH tmux oder screen einsetzen. Das Upgrade nicht direkt in der Shell der Weboberfläche ausführen, da diese unterbrochen wird. |
Schritt 1: PVE 8.4.1 sicherstellen
Zuerst alle Nodes auf den neuesten Stand bringen:
apt update && apt dist-upgrade
pveversion
Die Ausgabe muss pve-manager/8.4.1 oder höher zeigen. Falls nicht, erst updaten.
Schritt 2: Backups erstellen
Nicht verhandelbar. Vor jedem Major-Upgrade:
# Alle VMs und Container sichern (PBS oder lokaler Storage)
vzdump --all --mode snapshot --storage your-backup-storage
# Proxmox-Konfiguration sichern
tar czf /root/pve-config-backup-$(date +%Y%m%d).tar.gz /etc/pve/
# Bei Ceph: Ceph-Status dokumentieren
ceph status > /root/ceph-status-pre-upgrade.txt
ceph osd tree > /root/ceph-osd-tree-pre-upgrade.txt
Schritt 3: Upgrade-Check mit pve8to9 ausführen
Proxmox liefert ein Analyse-Tool mit, das potenzielle Probleme vor dem Upgrade erkennt:
pve8to9 --full
Das Tool prüft:
- Repository-Konfiguration
- Storage-Einstellungen
- Deprecated Optionen
- Paketversionen
- Container-Kompatibilität
FAIL-Einträge vor dem Upgrade beheben. Jede WARN-Meldung einzeln bewerten und die erforderlichen Maßnahmen umsetzen. Bei betroffenen Volumes auf gemeinsam genutztem LVM-Storage empfiehlt Proxmox ausdrücklich, die Autoaktivierung mit /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation zu deaktivieren.
Bei Clustern: pve8to9 --full auf jedem Node ausführen, bevor der erste Node upgraded wird.
Schritt 4: Ceph auf Squid upgraden
Wenn Ceph im Cluster läuft, ist dieser Schritt zwingend vor dem PVE-Upgrade. Ausgangspunkt ist Ceph Reef (18.2.4-pve3 oder neuer) auf PVE 8.2.8 oder neuer, der Cluster muss gesund sein. Der Ablauf folgt der offiziellen Anleitung Ceph Reef to Squid:
# Ceph-Status prüfen (muss HEALTH_OK sein)
ceph status
# Auf jedem Node: Ceph-Quelle von Reef auf Squid umstellen (PVE 8, Bookworm)
sed -i 's/reef/squid/' /etc/apt/sources.list.d/ceph.list
# Einmal im Cluster: noout-Flag setzen
ceph osd set noout
# Auf jedem Node: Pakete aktualisieren (die Dienste laufen danach noch mit Reef)
apt update
apt full-upgrade
# Monitore neu starten, ein Node nach dem anderen, danach Status prüfen
systemctl restart ceph-mon.target
ceph mon dump | grep min_mon_release # erwartet: min_mon_release 19 (squid)
# Manager und OSDs neu starten (OSDs nur auf einem Node gleichzeitig, danach ceph status prüfen)
systemctl restart ceph-mgr.target
systemctl restart ceph-osd.target
# Wenn alle OSDs Squid melden: Squid-Funktionen freischalten
ceph osd require-osd-release squid
# noout-Flag wieder entfernen
ceph osd unset noout
Bei CephFS folgt zusätzlich das Update der MDS-Daemons nach dem Abschnitt „Upgrade all CephFS MDS daemons“ der Anleitung.
Nach dem PVE-Upgrade beschreibt Proxmox den Wechsel von Ceph Squid auf Tentacle (20.2) als eigenen Schritt für PVE 9.1 oder neuer: Ceph Squid to Tentacle. PVE 9.2 führt Tentacle 20.2 als stabile Option neben Squid 19.2 (Roadmap). Auslegung und Betrieb von Ceph-Clustern: Proxmox Ceph.
Schritt 5: PBS auf Version 4 upgraden
Läuft der Proxmox Backup Server direkt auf einem PVE-Node mit, verweist der offizielle Upgrade-Pfad auf die eigene Anleitung PBS 3 auf 4; beide lassen sich gemeinsam aktualisieren, indem der Wechsel der APT-Repositories zusammengelegt wird. Einen separaten PBS-Host nennt die Anleitung nicht als Voraussetzung; wir aktualisieren ihn trotzdem vorab, damit Client und Server auf demselben Stand sind. PBS 4 basiert ebenfalls auf Debian 13 und ist kompatibel mit PVE 9. Für den separaten PBS-Host gilt der Ablauf der PBS-Anleitung, Voraussetzung ist PBS 3.4.2 oder neuer:
# Auf dem PBS-Host: Upgrade-Check und Version prüfen
pbs3to4 --full
proxmox-backup-manager versions
# Debian-Basisquellen auf Trixie umstellen
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
# PBS-4-Repository im Deb822-Format anlegen (No-Subscription;
# Enterprise: URIs https://enterprise.proxmox.com/debian/pbs, Components pbs-enterprise)
cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
# Alte PBS-3-Quelle (.list) entfernen oder auskommentieren, Ergebnis prüfen, dann upgraden
apt update
apt policy
apt dist-upgrade
reboot
Mehr zu PBS: Was ist der Proxmox Backup Server und Proxmox Backup Server einrichten und betreiben.
Schritt 6: APT-Repositories umstellen
Alle Quellen wechseln von Bookworm auf Trixie. Proxmox beschreibt dafür für PVE 9 das Deb822-Format (.sources) und entfernt die alten .list-Dateien nach der Umstellung (Upgrade-Anleitung, Abschnitt APT-Repositories):
# Debian-Basisquellen und (falls vorhanden) die alte Enterprise-Quelle auf Trixie umstellen
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list
# PVE-9-Repository im Deb822-Format anlegen (No-Subscription;
# Enterprise: Datei pve-enterprise.sources, URIs https://enterprise.proxmox.com/debian/pve, Components pve-enterprise)
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
# Nur bei Ceph: Ceph-Squid-Repository für Trixie (No-Subscription;
# Enterprise: URIs https://enterprise.proxmox.com/debian/ceph-squid, Components enterprise)
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
# Alte Bookworm-Quellen (pve-enterprise.list, ceph.list, pve-install-repo.list) entfernen
# oder auskommentieren, Backports-Zeilen entfernen, dann Ergebnis prüfen
apt update
apt policy
Wichtig: Entfernen Sie alle Verweise auf enterprise.proxmox.com, wenn Sie keinen aktiven Subscription-Key haben. Mischen Sie nicht Enterprise- und No-Subscription-Repos. Verbleibende .list-Einträge lassen sich nach dem Upgrade mit apt modernize-sources ins Deb822-Format überführen, die alten Dateien bleiben dabei als .list.bak erhalten. Zur Wahl des Repositories und zur Meldung „No valid subscription“: Proxmox Subscription-Meldung entfernen.
Schritt 7: Upgrade ausführen
apt dist-upgrade
Vor der Bestätigung die geplanten Installationen und Entfernungen lesen. Soll proxmox-ve entfernt werden, abbrechen und die Paketauflösung untersuchen. Rückfragen zu Konfigurationsdateien anhand der PVE-Upgrade-Anleitung beantworten.
Die Dauer hängt laut Upgrade-Anleitung stark von der Leistung des Systems ab, vor allem von IOPS und Bandbreite des Root-Dateisystems. Planen Sie pro Node ein Wartungsfenster ein.
Nach Abschluss:
# Reboot
reboot
# Nach dem Reboot: Version prüfen
pveversion
# Erwartete Ausgabe: pve-manager/9.x.x
Schritt 8: Post-Upgrade Checks
Nach dem Reboot diese Punkte verifizieren:
# Kernel-Version
uname -r
# Erwartet bei PVE 9.2: 7.0.x (PVE 9.1: 6.17, PVE 9.0: 6.14)
# Alle Services laufen?
systemctl --failed
# Web-Interface erreichbar?
curl -k https://localhost:8006
# Ceph-Status (falls vorhanden)
ceph status
# VM/CT-Status
qm list
pct list
Cluster-Upgrade-Strategie
Für Produktions-Cluster mit HA empfehlen wir diese Reihenfolge:
1. Vorbereitung (alle Nodes)
pve8to9 --fullauf jedem Node- Ceph auf Squid upgraden (falls vorhanden)
- PBS auf Version 4 upgraden (falls vorhanden)
2. Rolling Upgrade (Node für Node)
Node 1 → Maintenance Mode → Upgrade → Reboot → Verify → Exit Maintenance
Node 2 → Maintenance Mode → Upgrade → Reboot → Verify → Exit Maintenance
Node 3 → ...
3. Pro Node:
- Node in Maintenance Mode setzen (HA-Services werden migriert)
- VMs/CTs per Live-Migration auf andere Nodes verschieben
- Upgrade durchführen
- Reboot
- Post-Upgrade Checks
- Maintenance Mode beenden
4. Nach dem letzten Node:
- HA-Groups werden automatisch zu HA-Rules migriert
- Cluster-Status verifizieren:
pvecm status - Ceph-Status verifizieren:
ceph status
Wichtig: VMs können immer von einem älteren auf einen neueren PVE-Node migriert werden. Umgekehrt (PVE 9 → PVE 8) wird nicht offiziell unterstützt.
Typische Fehler und wie man sie vermeidet
1. Ceph nicht vor PVE upgraded
Das Upgrade schlägt fehl oder Ceph ist nach dem Reboot nicht erreichbar. Lösung: Immer die Reihenfolge einhalten: erst Ceph Squid, dann PVE 9 (einen mitinstallierten PBS nach dessen eigener Anleitung).
2. Enterprise-Repository ohne Subscription
apt dist-upgrade scheitert mit 401-Fehlern. Lösung: Enterprise-Repo entfernen, No-Subscription-Repo verwenden.
3. Meta-Paket proxmox-ve soll entfernt werden
APT möchte proxmox-ve deinstallieren. Vorgehen: Das Upgrade an dieser Stelle abbrechen und die Paketauflösung prüfen. Eine falsche oder gemischte Repository-Konfiguration ist ein möglicher Prüfpunkt, aus der Meldung allein lässt sich die Ursache aber nicht bestimmen. Sind alle benötigten Quellen auf trixie umgestellt, und gibt es noch Bookworm-Einträge? Das Meta-Paket nicht zur Umgehung der Meldung entfernen.
4. Container mit altem systemd (≤230) starten nicht
CentOS 7, Ubuntu 16.04 und ähnliche Container mit systemd ≤230 funktionieren nicht mehr unter PVE 9. Lösung: Vor dem Upgrade auf neuere OS-Versionen migrieren. Der PVE-8-Support ist im August 2026 ausgelaufen - dieser Schritt duldet also keinen Aufschub mehr. Die Voraussetzung steht unter „cgroup V1 Removal“ in den Known Upgrade Issues.
5. systemd-boot Paket
Der pve8to9-Check meldet das systemd-boot Paket. Bei PVE 8.1-8.4 Installationen wurde es automatisch mitinstalliert. Lösung: Kann sicher entfernt werden, sofern nicht manuell konfiguriert (Known Upgrade Issues).
6. VM-Migration scheitert im gemischten Cluster
Während des Rolling Upgrades können VMs manchmal nicht auf dem Zielnode starten. Lösung: VM manuell starten, CPU-Typ prüfen (muss auf beiden Nodes unterstützt werden).
Unser Vorgehen bei WZ-IT
Wir upgraden Proxmox-Cluster für Unternehmen mit einem standardisierten Prozess:
- Analyse - Bestandsaufnahme: Cluster-Topologie, Ceph-Layout, PBS-Version, Container-OS-Versionen
- Planung - Wartungsfenster definieren, Reihenfolge festlegen, Rollback-Strategie dokumentieren
- Backup - Vollständiges Backup aller VMs/CTs, Konfigurationen und Ceph-Status
- Upgrade - Rolling Upgrade Node für Node mit Monitoring
- Verifizierung - Post-Upgrade Checks, Performance-Baseline, HA-Test
- Dokumentation - Aktualisierte Infrastruktur-Dokumentation
Das Upgrade wird von einem erfahrenen Engineer durchgeführt - nicht von einem Skript. Bei Problemen sind wir direkt am System.
Proxmox-Upgrade lieber abgeben? Wir prüfen Ihre Umgebung und planen das Upgrade auf PVE 9 von der Analyse bis zur technischen Abnahme. Umfang und Wartungsfenster werden vorab bestätigt. Jetzt Termin vereinbaren | Wartung und Upgrade ansehen
Weiterführende Guides
- Proxmox Backup Server 4.2: S3-Storage ist stable - Was bei PBS 4.2 neu ist
- Verschlüsselte Proxmox Backups mit Hetzner Storage Box - Offsite-Backups einrichten
- Proxmox auf Hetzner installieren: Auto-Install Script - Frische PVE 9 Installation
- VMware zu Proxmox Migration - Von VMware ESXi zu PVE wechseln
- Private Cloud für KMUs: HA Proxmox Cluster - Cluster-Architektur für Unternehmen
Reguläre Paketupdates ohne Major-Wechsel behandelt Proxmox updaten. Den Ablauf je Node mit HA-Wartungsmodus und Abnahme beschreibt der Cluster-Update-Guide.
Quellen
Stand Oktober 2026.
- Proxmox VE 9.2 Release Notes
- Offizieller Upgrade-Pfad von Proxmox VE 8 auf 9
- Proxmox VE Support Lifecycle
- Proxmox VE FAQ mit Lifecycle-Tabelle
- Proxmox VE Roadmap mit Versionsständen
- Ceph Reef to Squid
- Ceph Squid to Tentacle
- Proxmox Backup Server: Upgrade von 3 auf 4
- Proxmox VE Administration Guide: System Software Updates











