Updates im Proxmox-Cluster — ohne Bauchgefühl

/01Was eine Update-Politik ist — und was „nie anfassen" bedeutet

Eine Update-Politik ist kein Vorsatz, sondern ein Dokument: Sie legt fest, welches Repository ein Cluster nutzt, wie eine neue Kernel-Version geprüft wird, bevor sie den Produktivbetrieb erreicht, in welcher Reihenfolge Knoten aktualisiert werden und was passiert, wenn ein Update den Betrieb stört. Fehlt dieses Dokument, bleibt nur eine Stimmung übrig — „läuft doch", bis es nicht mehr läuft.

Proxmox VE ist dabei kein gewöhnlicher Server. Es basiert auf Debian, läuft mit einer Verwaltungsoberfläche direkt am Netz erreichbar und hat vollen Zugriff auf jede virtuelle Maschine und jeden Container, der auf ihm läuft. Jede offene CVE im Kernel oder in den Kernpaketen ist an dieser Stelle keine abstrakte Zahl, sondern eine Angriffsfläche mit Zugriff auf den gesamten Bestand. Genau deshalb ist Patch-Management auf dem Hypervisor selbst keine Kür, sondern der Teil der Infrastruktur, an dem sich ein Einbruch am wenigsten lokal begrenzen lässt.

„Never change a running system" stammt aus einer Zeit isolierter Systeme ohne Internetanbindung. Bei einem Hypervisor mit Weboberfläche, SSH-Zugang und dauerhafter Netzanbindung ist der Satz keine Strategie mehr, sondern eine offene Rechnung: Jeder Monat ohne Update ist ein Monat, in dem bekannte Lücken bekannt bleiben, während der Cluster erreichbar ist. Die Alternative ist nicht „sofort jedes Update einspielen", sondern eine Reihenfolge, die Fehler abfängt, bevor sie den ganzen Betrieb erreichen. Darum geht es in diesem Artikel — nicht um das Patchen der Gastsysteme, sondern um die Update-Politik der Hypervisor-Ebene selbst: Repository, Kernel, Reihenfolge, Rückfallplan.

/02Drei Repositories, drei Zwecke

Proxmox VE bezieht Pakete aus drei möglichen Quellen, und sie sind nicht austauschbar. Laut Dokumentation ist das Enterprise Repository „the recommended repository and available for all Proxmox VE subscription users. It contains the most stable packages and is suitable for production use." Das No-Subscription Repository braucht dagegen keinen Lizenzschlüssel — „you do not need a subscription key to access this repository. It can be used for testing and non-production use" —, mit der ausdrücklichen Warnung: „It's not recommended to use this on production servers, as these packages are not always as heavily tested and validated." Das Test-Repository schließlich ist laut Dokumentation nur für Entwickler gedacht: „The pve-test repository should (as the name implies) only be used for testing new features or bug fixes."

Ein verbreitetes Missverständnis: Enterprise-Zugang sei teuer. Tatsächlich schaltet bereits die günstigste Abo-Stufe „Community" für 120 €/Jahr je CPU-Sockel den Zugriff auf das Enterprise Repository frei — ohne Ticket-Support durch das Proxmox-Team, aber mit denselben, am stärksten getesteten Paketen. Wer mehr will, zahlt für Support-Tickets, nicht für das Repository selbst: Basic (370 €/Jahr/Sockel, 3 Tickets), Standard (550 €/Jahr/Sockel, 10 Tickets, von Proxmox als Empfehlung markiert) und Premium (1.100 €/Jahr/Sockel, unbegrenzt Tickets). Alle Preise verstehen sich netto, je besetztem physischem CPU-Sockel und Jahr — die Kernzahl der Server spielt für den Preis keine Rolle, wohl aber, dass laut Lizenzbedingung in einem Cluster alle besetzten Sockel aller Knoten dieselbe Abo-Stufe tragen müssen.

Für die Update-Politik folgt daraus eine klare Trennung: Das Enterprise Repository ist die Standardquelle für jeden Knoten, der Gäste trägt. No-Subscription hat im Produktivcluster nichts zu suchen — es ist das Repository für genau die Maschine, die in Abschnitt 5 als Testknoten dient. Test bleibt draußen, auch dort.

/03Der Kernel ist die riskanteste Komponente

Nicht jedes Paket-Update trägt dasselbe Risiko. Ein aktualisiertes Web-Frontend-Paket betrifft die Oberfläche; ein fehlerhaftes Kernel-Update betrifft alles gleichzeitig, weil der Kernel Speicherverwaltung, Netzwerktreiber, Storage-Stack und die Virtualisierungs-Grundlage in einem Stück trägt. Sowohl KVM als auch LXC hängen an derselben Kernel-Version — ein Fehler dort trifft VMs und Container gleichzeitig, nicht nur eine der beiden Betriebsarten.

Proxmox VE 9 wechselte die Kernel-Hauptlinie zweimal in weniger als einem Jahr: Mit Version 9.1 vom 19.11.2025 wurde Kernel 6.17.2-1 „as new stable default" gesetzt, mit Version 9.2 vom 21.05.2026 übernahm Kernel 7.0 diese Rolle als „new stable default". Das ist kein Ausrutscher, sondern die übliche Kadenz: Proxmox VE zieht neuere Kernel-Linien in relativ kurzen Abständen nach, um aktuelle Hardware und Sicherheitskorrekturen zu tragen — mit dem Nebeneffekt, dass jede dieser Linien neu mit der vorhandenen Hardware kompatibel sein muss, von der Netzwerkkarte bis zum durchgereichten PCI-Gerät.

Nicht jede geschlossene Kernel-CVE verdient dieselbe Dringlichkeit. Zwei Kennzahlen helfen bei der Priorisierung: Der KEV-Katalog der US-Behörde CISA listet Schwachstellen, die nachweislich bereits aktiv ausgenutzt werden — steht eine geschlossene Kernel-Lücke dort, ist das Update kein Punkt für den nächsten Wartungsplan, sondern für diese Woche. Der EPSS-Wert schätzt umgekehrt die Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird, und hilft bei der Abwägung, wenn ein Kernel gleich mehrere geschlossene CVEs auf einmal mitbringt. Beide Werte ersetzen nicht die Testphase aus Abschnitt 5 — sie entscheiden nur, wie viel Zeit vor dem Rollout noch bleibt.

/04Eine Kernel-Version festhalten — und wieder lösen

Proxmox VE bootet über proxmox-boot-tool statt über ein klassisches GRUB-Setup, sobald das System-Root auf ZFS liegt oder mehrere EFI-System-Partitionen gespiegelt werden müssen — genau der Fall, in dem ein einzelner Bootloader-Eintrag nicht reicht, weil jede der beteiligten Partitionen denselben Kernel und dieselbe Initrd tragen muss. Dasselbe Werkzeug erlaubt es, eine bestimmte Kernel-Version festzuhalten, statt beim nächsten apt dist-upgrade automatisch auf die neueste installierte Version zu wechseln.

# installierte und verfügbare Kernel-Versionen anzeigen
proxmox-boot-tool kernel list

# eine Version dauerhaft festhalten (bootet bei jedem Neustart)
proxmox-boot-tool kernel pin 6.17.2-1-pve

# eine Version nur für den nächsten Neustart festhalten
proxmox-boot-tool kernel pin 6.17.2-1-pve --next-boot

# Festhalten wieder aufheben
proxmox-boot-tool kernel unpin

# nach jedem Pin/Unpin: Bootloader-Konfiguration neu schreiben
proxmox-boot-tool refresh

Der Unterschied zwischen den beiden Pin-Formen ist der zwischen einer dauerhaften Entscheidung und einem einmaligen Test. Die Variante mit --next-boot eignet sich, um nach einem missglückten Reboot kontrolliert auf die zuletzt funktionierende Version zurückzufallen, ohne die Festlegung dauerhaft zu setzen; die Variante ohne diese Option bleibt bestehen, bis sie ausdrücklich mit kernel unpin aufgehoben wird — inklusive jedes künftigen automatischen Updates, das sonst eine neuere Version installiert hätte.

Wer Secure Boot aktiviert hat, sollte vor dem Pinnen prüfen, dass die festgehaltene Version noch gültig signiert ist: Proxmox signiert seine Kernel-Pakete für den Secure-Boot-Betrieb, aber ein sehr alter, dauerhaft gepinnter Kernel kann irgendwann aus dem unterstützten Signaturbestand herausfallen. Ein Pin ist ein Werkzeug für den Übergang, kein Ersatz für die Entscheidung, wann der Übergang endet.

/05Der Testknoten vor dem Cluster

Ein Testknoten ist keine Kulanz, sondern die günstigste Versicherung, die es in diesem Prozess gibt: eine Maschine, die keine Produktivlast trägt, dieselbe Hardwaregeneration und dieselben Netzwerk- und Storage-Treiber wie der Cluster verwendet und bewusst auf dem No-Subscription Repository läuft — genau dort, wo dieses Repository laut Abschnitt 2 hingehört. Ein neues Kernel- oder Paket-Update erreicht zuerst diesen Knoten, nie direkt den Cluster.

Der Testlauf braucht repräsentative Last, nicht nur ein leeres System: mindestens eine VM und ein Container, ein durchgereichtes PCI-Gerät, falls im Cluster verwendet, und dieselbe Netzwerkkonfiguration wie produktiv. Vor dem Testlauf lohnt sich ein Snapshot der Testgäste — nicht, um das Update rückgängig zu machen, sondern um nach einem missglückten Test schnell wieder einen sauberen Ausgangszustand für den nächsten Versuch zu haben, statt den Testknoten jedes Mal neu aufzusetzen.

Ein sinnvoller Prüfumfang nach dem Update: Bootet der Knoten ohne manuellen Eingriff, sind alle Netzwerkschnittstellen mit den erwarteten Namen da, funktioniert das durchgereichte Gerät weiterhin, zeigt dmesg keine neuen Fehler im Bereich IOMMU oder Storage-Treiber. Ein bis zwei Tage Beobachtungszeit fangen die Fehler ab, die erst nach einiger Laufzeit auftreten — genau die Art von Regression, die Abschnitt 7 beschreibt. Erst wenn dieser Zeitraum ohne Befund verstreicht, wechselt das Update auf den Cluster.

/06Die Reihenfolge beim rollierenden Update

Im Cluster wird nie mehr als ein Knoten gleichzeitig aktualisiert. Der Grund liegt im Quorum: Proxmox VE braucht eine Mehrheit der stimmberechtigten Knoten, um Cluster-Entscheidungen zu treffen, und ein Knoten im Neustart zählt für diese Mehrheit vorübergehend nicht mit. Bei drei Knoten verträgt der Cluster genau einen gleichzeitig fehlenden, ohne das Quorum zu verlieren — bei zwei gleichzeitig aktualisierten Knoten stünde ein Drei-Knoten-Cluster ohne Mehrheit da.

# 1. Quorum und Knotenstatus vor Beginn prüfen
pvecm status

# 2. laufende Gäste per Live-Migration auf andere Knoten verschieben
#    (oder: Wartungsmodus, der HA-Ressourcen automatisch verschiebt)
ha-manager crm-command node-maintenance enable pve03

# 3. Repository-Stand und Pakete aktualisieren
apt update && apt dist-upgrade

# 4. Knoten neu starten
reboot

# 5. nach dem Neustart: Quorum, Ceph-Status und Netzwerk prüfen,
#    bevor der nächste Knoten beginnt
pvecm status
ceph -s

# 6. Wartungsmodus beenden, Gäste bei Bedarf zurückverschieben
ha-manager crm-command node-maintenance disable pve03

Schritt 2 ist der Grund, warum ein Cluster überhaupt rollierend statt gleichzeitig aktualisiert werden kann: Live-Migration verschiebt laufende VMs im laufenden Betrieb auf einen anderen Knoten, ohne sie herunterzufahren. Container lassen sich je nach Speicher-Backend ebenfalls live oder mit kurzer Pause umziehen. Erst wenn der Knoten leer ist, folgt das eigentliche Update und der Neustart.

Wer Ceph als Storage-Backend nutzt, prüft nach jedem Knoten-Neustart zusätzlich den Cluster-Status, bevor der nächste Knoten beginnt: Ceph braucht Zeit, um nach dem Ausfall eines Members die Redundanz wiederherzustellen, und ein zweiter Neustart mitten in diesem Wiederherstellungsfenster kann die Datenverfügbarkeit gefährden, selbst wenn beide Knoten für sich genommen sauber hochfahren. Wer High Availability mit automatischem Fencing einsetzt, sollte den betroffenen Knoten vor dem geplanten Neustart in den Wartungsmodus versetzen — sonst wertet der Cluster den geplanten Neustart im schlechtesten Fall als Ausfall und fenct einen Knoten, der ohnehin gerade plangemäß offline ist.

/07Regressionen und der Rückfallplan

Eine Regression ist kein Zeichen dafür, dass Updates falsch sind — sie ist der Beweis, dass der Testknoten aus Abschnitt 5 seinen Zweck erfüllt, wenn sie dort auftaucht, statt erst im Cluster. Zwei Praxisbeobachtungen aus dem Proxmox-Forum zeigen, wie konkret das wird — es handelt sich um Nutzerberichte, nicht um bestätigte Herstellerangaben.

Im März 2026 meldeten mehrere Nutzer in einem Forumsthread DMAR-Fehler beim PCI-Passthrough über VFIO, die nach einigem Betrieb auftraten: Kernel 6.17.9-1-pve lief stabil, nach dem Update auf 6.17.13-1-pve beziehungsweise 6.17.13-2-pve traten die Fehler auf — ein Hinweis auf eine Regression innerhalb derselben Kernel-Hauptlinie, nicht erst beim Wechsel auf eine neue. Ein Nutzer berichtete nach dem Setzen des Kernel-Parameters intel_iommu=sp_off in /etc/kernel/cmdline: „No a single error so far." Eine offizielle Bestätigung durch Proxmox-Entwickler war im Thread zum Zeitpunkt der Prüfung nicht zu sehen, ein Proxmox-Mitarbeiter hatte jedoch um weitere Logs gebeten.

Im Mai 2026 beschrieb ein zweiter Thread einen Fall, in dem ein Knoten nach dem Update auf proxmox-kernel-7.0.0-3-pve die Netzwerkverbindung verlor: Die Netzwerkschnittstellen erschienen als DOWN, die erwarteten Bridge-Interfaces fehlten in der Konfiguration. Ursache war in diesem konkreten Fall ein Drittanbieter-Kernelmodul (ein DKMS-Treiber für Fusion-IO-Speicherkarten), das mit der Signaturprüfung des neuen Kernels nicht kompatibel war — ein Muster, das sich auf jedes Setup mit nachträglich installierten DKMS-Treibern übertragen lässt. Zusätzlich berichten Nutzer allgemeiner von veränderten Namen für Netzwerkschnittstellen zwischen der 6.17- und der 7.0-Linie; wo eine Schnittstelle vorher eth0 hieß, kann sie danach anders benannt sein, was bestehende Bridge-Konfigurationen bricht, bis die Namen manuell nachgezogen oder Interface-Pinning eingerichtet wird.

Der Rückfallplan gehört als Runbook dokumentiert, nicht ins Gedächtnis der Person, die zufällig Dienst hat: die zuletzt funktionierende Kernel-Version vor dem Update notieren, klare Abbruchkriterien festlegen (fehlende Netzwerkschnittstelle, IOMMU-Fehler in dmesg, HA-Ressourcen, die nicht wieder starten), und den Rückweg als Befehlsfolge bereithalten:

# dmesg nach den bekannten Fehlermustern durchsuchen
dmesg | grep -iE "dmar|iommu fault"

# zuletzt funktionierende Version erneut festhalten
proxmox-boot-tool kernel pin 6.17.9-1-pve
proxmox-boot-tool refresh
reboot

Ein Rückfallplan, der erst während eines laufenden Vorfalls entsteht, kostet doppelt: die Zeit, das Problem einzugrenzen, und die Zeit, währenddessen einen Befehl nachzuschlagen, der eigentlich vorher hätte feststehen sollen.

/08Wann sich eine strikte Update-Politik lohnt — und wann nicht

Dafür spricht

• Der Cluster trägt Produktivlast mit Internetanbindung: Jede erreichbare Verwaltungsoberfläche ist ein Ziel, und ungeschlossene Kernel-CVEs bleiben genau dort offen, wo der Zugriff am weitesten reicht.
• Mehr als ein Knoten steht bereit: Erst ab zwei Knoten lässt sich überhaupt rollierend aktualisieren, ohne den Betrieb für die Dauer eines Neustarts komplett zu unterbrechen.
• Es laufen durchgereichte Geräte oder ungewöhnliche Hardware: Genau dort schlagen Kernel-Regressionen laut den Forumsfällen aus Abschnitt 7 am häufigsten zu — Standardhardware mit Standardtreibern ist seltener betroffen.
• Hochverfügbarkeit ist im Einsatz: Wo Fencing automatisch eingreift, verhindert eine geordnete Reihenfolge, dass ein geplanter Neustart als Ausfall gewertet wird.

Dagegen spricht

• Ein einzelner Knoten ohne Ausweichkapazität: Ohne zweiten Knoten gibt es kein Ziel für Live-Migration und keinen echten Testknoten — die Reihenfolge aus Abschnitt 6 lässt sich dann nicht umsetzen, nur ein sorgfältiges Zeitfenster mit Rückfallplan.
• Reine Labor- oder Entwicklungsumgebungen ohne Netzanbindung nach außen: Hier wiegt das Risiko einer offenen CVE deutlich weniger, ein strikter Testknoten-Prozess kostet dann mehr Aufwand, als er einspart.
• Kein Budget für einen dedizierten Testknoten: Ohne eigene Testmaschine bleibt nur, das Risiko auf den am wenigsten kritischen Produktivknoten zu verlagern — besser als gar keine Reihenfolge, aber kein vollwertiger Ersatz.

Die meisten KMU-Cluster liegen zwischen diesen Extremen: zwei bis vier Knoten, Produktivlast, aber kein eigenes Testlabor. Für dieses Profil trägt bereits ein einzelner, dauerhaft auf No-Subscription betriebener Knoten außerhalb der Produktivrolle den größten Teil des Nutzens — die 120 €/Jahr für dessen Enterprise-Repository-Zugang während der kurzen Übergangsphase, in der er testet und dann produktiv mitläuft, sind gegen die Kosten eines Wochenend-Ausfalls kein ernsthafter Kostenfaktor.

/09Häufige Fragen