Proxmox VE 8 ist ohne Support: Upgrade auf 9 ohne Stillstand

/01Was „Support-Ende" bedeutet — und was nicht

Das Support-Ende einer Proxmox-Version ist keine Abschaltung. Ein Cluster auf Proxmox VE 8 läuft am 1. September genauso wie am 31. August, die Gäste starten, die Live-Migration funktioniert, das Backup läuft. Was sich ändert, steht in der Support-Tabelle des Proxmox-FAQ: Für Version 8 auf Basis von Debian 12 „Bookworm" ist der EOL-Monat August 2026 eingetragen, für Debian selbst der Juli 2026. Die Weboberfläche formuliert es seit Wochen unmissverständlich als Banner: „Unterstützung für Proxmox VE 8 endet am 2026-08-31". Nach diesem Datum kommen keine Paketaktualisierungen mehr — und vor allem keine Sicherheitsfixes.

Die Grundregel steht ebenfalls im FAQ: Proxmox-Versionen werden mindestens so lange unterstützt, wie das zugrunde liegende Debian vom Debian-Security-Team versorgt wird, also etwa drei Jahre nach dem ersten Release. Proxmox VE 8 erschien im Juni 2023; die drei Jahre sind um. Version 9 auf Debian 13 „Trixie" gibt es seit dem 5. August 2025 — Proxmox hat damit gut ein Jahr Überlappung gelassen, in dem beide Versionen gepflegt wurden. Dieses Jahr ist vorbei.

Was dieser Artikel nicht behandelt: die Neuinstallation. Wer einen Cluster ohnehin neu aufbaut, etwa weil die Hardware wechselt, installiert Proxmox VE 9.2 direkt und migriert die Gäste. Hier geht es um den Bestand: Knoten, die seit Jahren laufen, mit Konfiguration, Storage-Anbindung und Gästen, die niemand neu anlegen will.

/02Warum ein Hypervisor ohne Patches anders zählt als ein Fileserver

Ein Proxmox-Knoten ist kein gewöhnlicher Server. Er hat Zugriff auf den Arbeitsspeicher und die Platten jeder virtuellen Maschine, die auf ihm läuft, seine Weboberfläche und der SSH-Zugang hängen am Netz, und er teilt sich mit den anderen Knoten das Cluster-Dateisystem. Eine offene CVE im Kernel, in QEMU oder im Verwaltungsdienst ist an dieser Stelle keine lokale Angelegenheit, sondern eine Angriffsfläche mit Reichweite auf den gesamten Bestand. Das ist der Grund, warum Patch-Management auf der Hypervisor-Ebene keine Kür ist — auf keiner Plattform, und bei Proxmox nicht anders als bei VMware oder Hyper-V.

In der Praxis: Die Diskussion „läuft doch stabil, warum anfassen" führt jeder Administrator einmal mit seiner Geschäftsführung. Das Argument ist nicht falsch — es ist nur unvollständig. Ein Cluster, der stabil läuft und keine Patches mehr bekommt, ist stabil bis zur ersten öffentlich bekannten Lücke, und ab dann läuft eine Uhr, die niemand im Haus stellen kann. Wer eine Cyber-Versicherung hat oder unter NIS2 fällt, hat zusätzlich einen Nachweis zu führen: Ein Hypervisor ohne Herstellersupport ist in beiden Fragebögen eine Antwort, die man nicht geben möchte.

Das ist keine Formsache. Es ist aber auch kein Grund für Hektik. Ein Upgrade, das übers Wochenende ohne Vorbereitung durchgedrückt wird, richtet mehr Schaden an als vier Wochen Betrieb ohne Patches. Der Rest dieses Artikels ist die Vorbereitung.

/03Voraussetzungen: 8.4.1, Ceph Squid, freier Platz, Sicherung

Die Upgrade-Anleitung im Proxmox-Wiki nennt harte Voraussetzungen, und sie sind nicht verhandelbar. Alle Knoten müssen mindestens Proxmox VE 8.4.1 laufen — wer noch auf 8.2 oder 8.3 steht, aktualisiert zuerst innerhalb der 8er-Linie. Hyperkonvergente Ceph-Cluster müssen vor dem Proxmox-Upgrade auf Ceph 19.2 „Squid" stehen; der Pfad von Quincy oder Reef führt über die jeweiligen Zwischenversionen, und jeder Schritt ist ein eigenes Wartungsfenster. Läuft ein Proxmox Backup Server auf demselben Host, wird er zuerst von 3 auf 4 gehoben. Im Root-Dateisystem müssen mindestens 5 GB frei sein, Proxmox empfiehlt 10 GB oder mehr.

Zwei Voraussetzungen, die nicht in Versionsnummern stehen: ein unabhängiger Zugang zum Knoten und eine geprüfte Sicherung. Die Anleitung empfiehlt IPMI, iKVM oder physischen Zugang — weil nach dem Upgrade Netzwerkschnittstellen anders heißen können und ein Knoten, der nur per SSH erreichbar war, dann nicht mehr erreichbar ist. Und sie formuliert zur Sicherung: „A valid and tested backup is always required before starting the upgrade process." Getestet heißt getestet — eine Rücksicherung in ein Testsystem, nicht eine grüne Zeile im Backup-Log. Wie man einen Restore misst statt vermutet, steht in Restore-Test: RTO messen statt schätzen.

/04Das Prüfskript pve8to9 lesen, nicht nur ausführen

Proxmox liefert mit dem Paket pve-manager der 8er-Linie das Skript pve8to9 aus. Es verändert nichts am System, sondern prüft: Versionen, Repositories, Cluster-Zustand, Ceph, Storage-Konfiguration, bekannte Problemfälle. Mit --full sind alle Prüfungen aktiv, auch die aufwendigeren. Die Ausgabe teilt sich in PASS, WARN und FAIL — und der häufigste Fehler in der Praxis ist, WARN als „geht schon" zu lesen.

# Auf jedem Knoten, vor dem Upgrade, mehrfach:
pve8to9 --full

# Typische Ausgabe (gekürzt)
= CHECKING VERSION INFORMATION FOR PVE PACKAGES =
PASS: proxmox-ve package has version >= 8.4-1
= CHECKING CLUSTER HEALTH AND SETTINGS =
PASS: Cluster is quorate.
= CHECKING HYPER-CONVERGED CEPH STATUS =
PASS: ceph 19.2 squid detected
= MISCELLANEOUS CHECKS =
WARN: systemd-boot meta-package installed ...
WARN: 3 guest(s) with cgroup v1 ...
= SUMMARY =
TOTAL:    41
PASSED:   36
WARNINGS:  4
FAILURES:  1

Jede WARN-Zeile hat im Wiki einen Abschnitt, der sagt, was zu tun ist. Die beiden aus dem Beispiel sind typisch: Das Meta-Paket systemd-boot wurde von den Installationsmedien der Versionen 8.1 bis 8.4 automatisch mitinstalliert und soll entfernt werden, sofern man den Bootloader nicht bewusst selbst pflegt (apt remove systemd-boot). Und Container mit einem systemd älter als Version 230 — CentOS 7, Ubuntu 16.04 — laufen unter Proxmox VE 9 nicht mehr, weil cgroup v1 entfernt ist und nur noch cgroup v2 existiert. Diese Container müssen vor dem Upgrade migriert oder ersetzt werden; danach ist der Weg zu.

Das Skript läuft mehrfach: einmal zur Bestandsaufnahme, dann nach jeder Korrektur, und ein letztes Mal unmittelbar vor dem Upgrade. Wer es nur einmal laufen lässt und die Ausgabe nicht speichert, hat später keine Grundlage mehr für die Frage, was vorher schon warnte und was das Upgrade verursacht hat.

/05Die Reihenfolge im Cluster: Gäste wegschieben, Knoten für Knoten

„Ohne Stillstand" ist im Cluster keine Kunst, sondern Reihenfolge. Die Anleitung sagt es ausdrücklich: Ein Knoten nach dem anderen, und mit dem nächsten erst beginnen, wenn der vorherige fertig und wieder im Cluster ist. Vor dem Upgrade eines Knotens wandern seine Gäste per Live-Migration auf die anderen. Dafür gilt eine Regel, die Proxmox wörtlich so formuliert: Die Migration von einem älteren auf einen neueren Knoten funktioniert immer; die Migration von einem neueren auf einen älteren mag funktionieren, ist aber grundsätzlich nicht unterstützt. Daraus folgt die Planung: Gäste werden von 8er-Knoten auf 8er-Knoten geschoben, bis der erste Knoten auf 9 steht — und dann von 8 auf 9, nie zurück.

# Knoten pve01 leeren: alle Gaeste auf pve02 (nur Beispiel, HA beachtet Regeln selbst)
for vm in $(qm list | awk 'NR>1 {print $1}'); do
    qm migrate $vm pve02 --online
done
for ct in $(pct list | awk 'NR>1 {print $1}'); do
    pct migrate $ct pve02 --restart
done

# Danach: Quorum pruefen, bevor der Knoten in Wartung geht
pvecm status | grep -E 'Quorate|Expected votes|Total votes'

Zwei Punkte zum Quorum: Ein Drei-Knoten-Cluster bleibt mit zwei Knoten beschlussfähig, ein Zwei-Knoten-Cluster nicht — wer nur zwei Knoten hat, braucht ein QDevice oder ein Wartungsfenster, in dem HA bewusst ausgesetzt wird. Proxmox VE 9.2 bringt dafür die Funktion, HA clusterweit zu „entwaffnen" (Disarm) und nach der Wartung wieder zu aktivieren, wobei der vorherige Zustand automatisch wiederhergestellt wird. Das ersetzt das früher übliche manuelle Umstellen der HA-Ressourcen — allerdings erst, wenn der Cluster bereits auf 9.2 steht. Beim ersten Knoten hilft es also noch nicht.

Für die Dauer des Upgrades läuft ein gemischter Cluster mit 8er- und 9er-Knoten. Das ist vorgesehen, aber mit einer dokumentierten Einschränkung: Wer in der Oberfläche eines bereits aktualisierten Knotens angemeldet ist und Aktionen auf einem noch alten Knoten ausführt, kann kleinere Unstimmigkeiten sehen. Die Praxis-Regel daraus: Während der Übergangsphase in der Oberfläche eines 8er-Knotens arbeiten, bis alle auf 9 sind — und den gemischten Zustand auf Tage begrenzen, nicht auf Wochen. Wie Corosync in dieser Phase reagiert, wenn ein Knoten länger als erwartet neu startet, beschreibt der Artikel zu Corosync und Fencing.

/06Repositories umstellen und das Upgrade fahren

Das eigentliche Upgrade ist ein Debian-Distributionswechsel von Bookworm auf Trixie mit Proxmox-Paketen obendrauf. Erst wird der Knoten auf den letzten Stand der 8.4 gebracht, dann werden die Paketquellen umgestellt, dann läuft apt dist-upgrade. Proxmox VE 9 nutzt das deb822-Format für die Paketquellen; die alten .list-Dateien werden ersetzt.

# 1. Letzter Stand der 8.4
apt update && apt dist-upgrade
pveversion            # 8.4.1 oder neuer

# 2. Debian-Quellen auf trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# 3. Proxmox-Enterprise-Quelle im deb822-Format
cat > /etc/apt/sources.list.d/pve-enterprise.sources << EOF
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
rm /etc/apt/sources.list.d/pve-enterprise.list

# 4. Quellen pruefen — keine Fehler, keine fremden Repositories
apt update
apt policy

# 5. Upgrade — nur in der Konsole oder in tmux/screen
apt dist-upgrade

# 6. Neustart, auch wenn der 6.14er-Kernel schon lief
reboot

# 7. Nachkontrolle
pve8to9
pveversion            # 9.x

Während apt dist-upgrade fragt Debian bei geänderten Konfigurationsdateien nach. Die Anleitung gibt Empfehlungen: /etc/issue behalten (kosmetisch), /etc/lvm/lvm.conf und /etc/chrony/chrony.conf auf die Maintainer-Version, wenn nicht selbst geändert, /etc/ssh/sshd_config auf die Maintainer-Version, weil sie die veraltete Option ChallengeResponseAuthentication ablöst, /etc/default/grub behalten, wenn von Hand bearbeitet. Wer diese Fragen nicht vorbereitet hat, entscheidet unter Zeitdruck — und ein falsches „Maintainer-Version" bei der GRUB-Konfiguration kostet den nächsten Neustart.

Der Neustart ist Pflicht, auch wenn der Kernel 6.14 bereits unter der 8.4 lief: Die Anleitung begründet das mit der ABI-Kompatibilität der neuen Pakete. Nach dem Neustart läuft pve8to9 ein letztes Mal und sollte keine offenen Punkte mehr zeigen. Wer den Ziel-Stand 9.2 will, hängt danach ein weiteres apt dist-upgrade an — die Trixie-Quellen liefern die aktuelle Punktversion direkt mit, und mit 9.2 kommen Kernel 7.0 und QEMU 11.0 als Standard. Was der Kernelwechsel für die Update-Politik bedeutet, steht in Kernel-Pinning und Reihenfolge im Proxmox-Cluster.

Sind alle Knoten auf 9, wandelt Proxmox die alten HA-Gruppen automatisch in HA-Regeln um — Version 9 kennt keine Gruppen mehr, sondern Node-Affinity- und Resource-Affinity-Regeln. Die Umwandlung lässt sich im Protokoll des Cluster-Resource-Managers nachlesen (journalctl -eu pve-ha-crm) und gehört zur Abnahme.

/07Ceph: Squid vorher, Tentacle nachher

Bei hyperkonvergentem Ceph ist die Reihenfolge zweistufig, und beide Stufen haben ihre eigene Wiki-Seite. Vor dem Proxmox-Upgrade muss Ceph auf 19.2 „Squid" stehen — das ist die Bedingung, die pve8to9 prüft. Nach dem Proxmox-Upgrade kann Ceph auf 20.2 „Tentacle" gehoben werden, die Version, die Proxmox VE 9.2 als aktuellen Stand mitliefert. Die Anleitung „Ceph Squid to Tentacle" setzt dafür voraus, dass alle Knoten mindestens Proxmox VE 9.1 mit pve-manager 9.1.4 laufen und die Ceph-Pakete mindestens 19.2.3-pve3 sind. Tentacle vor dem Proxmox-Upgrade geht also nicht, und Squid überspringen auch nicht.

# Ceph Squid -> Tentacle, erst wenn ALLE Knoten auf PVE 9.1+ stehen
ceph -s                           # HEALTH_OK ist Voraussetzung
ceph osd set noout

# Auf jedem Knoten nacheinander:
sed -i 's/squid/tentacle/' /etc/apt/sources.list.d/ceph.sources
apt update && apt full-upgrade

# Dienste in dieser Reihenfolge, je Knoten nacheinander:
systemctl restart ceph-mon.target       # zuerst alle Monitore
ceph mon dump | grep min_mon_release    # "min_mon_release 20 (tentacle)"
systemctl restart ceph-mgr.target       # dann die Manager
systemctl restart ceph-osd.target       # dann die OSDs, Knoten fuer Knoten

# Abschluss
ceph versions
ceph osd require-osd-release tentacle
ceph osd unset noout

Ein Detail aus dem 9er-Upgrade, das Ceph-Betreiber überrascht: Ceph Squid ab 19.2.6 markiert Schlüssel mit dem alten Verschlüsselungstyp aes als unsicher (CVE-2025-30156) und setzt den Cluster auf HEALTH_ERR, obwohl alle Dienste weiterlaufen. Die Schlüsselmigration gehört nach dem Upgrade aller Knoten auf die Liste, nicht mitten hinein. Und wer ein Ceph-Full-Mesh mit eigener FRR-Konfiguration betreibt, prüft die post-up-Zeile in /etc/network/interfaces: Ein bedingungsloses systemctl restart frr.service bricht unter Version 9, die Anleitung nennt die korrigierte Form mit is-active --quiet. Für den Aufbau eines Ceph-Clusters von Grund auf bleibt der Ceph-Grundlagenartikel die Referenz.

/08Bekannte Bruchstellen nach dem Upgrade

Die Liste der bekannten Probleme im Wiki ist lang, und das ist eine gute Nachricht: Sie ist lang, weil sie gepflegt wird. Sechs Punkte treffen Mittelstandscluster erfahrungsgemäß am häufigsten.

Netzwerkschnittstellen heißen anders

Der neue Kernel erkennt zusätzliche Hardware-Eigenschaften, und daraus kann ein anderer Schnittstellenname entstehen — enp3s0f0 wird zu enp3s0f0np0, die Bridge findet ihren Port nicht mehr, der Knoten ist vom Netz. Deshalb der IPMI-Zugang. Proxmox liefert das Werkzeug pve-network-interface-pinning, das Schnittstellen auf feste Namen nicX festlegt; wer es vor dem Upgrade einsetzt, hat das Problem nicht.

LVM-Autoaktivierung auf Shared Storage

Unter Version 9 werden neue Gast-Volumes ohne Autoaktivierung angelegt; bestehende Volumes behalten sie. Für LVM auf gemeinsamem iSCSI- oder Fibre-Channel-Storage empfiehlt Proxmox das mitgelieferte Migrationsskript /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation ausdrücklich — sonst aktiviert jeder Knoten beim Start jedes Volume der Volume Group, auch die, die gerade ein anderer Knoten nutzt.

GRUB findet die Root-LV nicht

Systeme mit Root auf LVM im UEFI-Modus können nach dem Upgrade mit disk 'lvmid/...' not found stehen bleiben. Die Abhilfe steht im Wiki und gehört vor den Neustart: [ -d /sys/firmware/efi ] && apt install grub-efi-amd64. ZFS-Root und Legacy-BIOS sind nicht betroffen.

/tmp liegt im Arbeitsspeicher

Debian 13 legt /tmp als tmpfs an, das bis zur Hälfte des Arbeitsspeichers belegen darf und im Betrieb regelmäßig bereinigt wird. Skripte, die dort große Dateien ablegen oder Ergebnisse über Tage erwarten, brechen — leise.

sysctl.conf wird ignoriert

/etc/sysctl.conf wird nicht mehr gelesen. Eigene Einstellungen — etwa für IP-Forwarding oder Netzwerkpuffer — wandern nach /etc/sysctl.d/NN-name.conf mit zweistelliger Ordnungszahl.

Veeam und QEMU-Maschinenversion 10

Wer Veeam für Proxmox einsetzt: Die Sicherung ist laut Wiki für VMs mit QEMU-Maschinenversion 10.0 oder neuer defekt. Der genannte Ausweg ist, die Maschinenversion auf 9.2+pve1 festzuhalten oder das Upgrade zu verschieben, bis Veeam nachzieht. HostSpezial setzt Veeam nicht ein; für Kunden, die es tun, ist das der Punkt, an dem das Upgrade-Datum vom Backup-Hersteller abhängt und nicht von Proxmox.

Dazu kommen zwei Punkte für Spezialfälle: PCI-Passthrough startet unter dem 6.14er-Kernel bei manchen Karten nicht, der Ausweg ist ein festgehaltener älterer Kernel; und die Speicheranzeige einer VM kann über 100 Prozent liegen, wenn der Gast keine Speicherdetails meldet — FreeBSD, pfSense, OPNsense, Windows ohne Balloon-Dienst. Das ist eine Anzeige, kein Fehler. Drittanbieter-Storage-Plugins schließlich brauchen möglicherweise eine neue Version; das ist vor dem Upgrade beim Hersteller zu klären, nicht danach im Forum.

/09Wann Sie das Upgrade verschieben sollten — und wann nicht

Die ehrliche Antwort auf „müssen wir sofort" lautet: nein, aber bald, und mit Plan. Ein Cluster auf 8.4 ohne Patches ist für einige Wochen ein kalkulierbares Risiko, wenn die Weboberfläche nicht aus dem Internet erreichbar ist und die Gäste selbst gepatcht bleiben. Ein halbes Jahr ist es nicht mehr.

Dafür spricht, jetzt zu gehen

• Das Prüfskript ist grün oder gelb: Keine FAIL-Zeilen, die WARN-Zeilen haben einen bekannten Ausweg. Dann ist die Vorbereitung im Wesentlichen erledigt.
• Ceph steht bereits auf Squid: Die aufwendigste Vorstufe entfällt, das Upgrade ist ein Wartungsfenster je Knoten.
• Sie wollen Funktionen der 9.2: Dynamischer Lastausgleich, Snapshots auf Shared LVM, HA-Disarm — all das gibt es nur auf Version 9, und der Überblick steht in Proxmox VE 9 und Datacenter Manager 1.0.
• Ein Audit, eine Versicherungsprüfung oder ein NIS2-Nachweis steht an: „Hersteller-Support beendet" ist eine Zeile, die man dort nicht stehen haben will.

Dagegen spricht — vorerst

• Container mit systemd vor Version 230 laufen produktiv: Die müssen erst ersetzt werden, und das ist ein eigenes Projekt.
• Ein Drittanbieter — Backup, Storage-Plugin — hat Version 9 noch nicht freigegeben: Dann bestimmt dieser Hersteller den Termin, nicht Proxmox.
• Ceph steht auf Quincy oder Reef: Zwei bis drei Ceph-Upgrades vorweg sind mehr Aufwand als das Proxmox-Upgrade selbst; das ändert nichts an der Notwendigkeit, aber am Zeitplan.
• Kein unabhängiger Zugang zu den Knoten: Ohne IPMI oder Vor-Ort-Zugang ist ein umbenanntes Netzwerkinterface ein Ausfall statt einer Fußnote. Das nachzurüsten kommt vor dem Upgrade.

Unsere Praxis-Linie: Testknoten oder Testcluster zuerst, dann der Knoten mit den unkritischsten Gästen, dann der Rest — mit einem Tag Abstand zwischen den Knoten, damit ein Problem sichtbar wird, bevor es den zweiten trifft. Das Upgrade selbst ist je Knoten erfahrungsgemäß eine Sache von etwa einer Stunde. Die Vorbereitung dauert länger, und das ist richtig so.

/10Häufige Fragen