Newsletter

    Newsletter abonnieren

    Neue Infrastruktur-Guides, Vergleichsberichte und Migrationshinweise direkt ins Postfach.

    Infrastruktur-Notizen, Guides und neue Tools. Jederzeit abbestellbar.

    Zurück zum Blog
    Proxmox
    Container
    Storage
    Backup

    Update drücken und beten: Das Proxmox-9.2-Upgrade macht Admins aufgeregt, nervös und lässt sie schon jetzt ihre Backups prüfen

    25. Mai 2026
    9 Min. Lesezeit

    Das Upgrade, das alle wollen, dem aber niemand ganz traut

    Proxmox VE 9.2 entwickelt sich zu einem jener Upgrades, die aufregend klingen – bis einem einfällt, welche Art von Maschinen davon betroffen sein wird. Das sind keine Wegwerf-Laptops oder Testkisten im Abstellraum. Für viele Leute ist Proxmox das, was das ganze Zuhause, das Lab oder das Kleinunternehmen zusammenhält. VMs, LXCs, NAS-Setups, GPU-Passthrough, Backup-Jobs, eigenartiges Intel-Networking, Hausautomation, Medienserver, die eine Windows-VM, von der niemand zugeben will, dass sie geschäftskritisch ist. Wenn also jemand sagt, er freue sich auf besseres ZFS und neue Funktionen, dann kommt diese Freude mit einer Hand, die über dem Notfall-Rollback-Plan schwebt.

    Das ist die Stimmung: halb Weihnachtsmorgen, halb Bombenentschärfung. Eine Person brachte es perfekt auf den Punkt: „Einfach die Augen zu und Update drücken, dann beten." Das ist witzig, weil es schmerzhaft genau trifft, wie sich Infrastruktur-Upgrades anfühlen, besonders wenn der Kernel auf Linux 7.0 springt und alle anfangen, ihre IOMMU-Gruppen anzustarren, als könnten die sich aus reiner Boshaftigkeit neu sortieren. Das Aushängeschild-Feature mag Stabilität, besseres Storage-Verhalten und das Versprechen einer saubereren Zukunft sein, aber die eigentliche Geschichte ist Vertrauen. Proxmox-Nutzer wollen das glänzende neue Ding. Sie wollen aber auch, dass ihre Laufwerks-Arrays, NICs und GPU-Passthrough-Setups genau dort wieder aufwachen, wo sie sie zurückgelassen haben.

    Linux 7.0 klingt beängstigend, bis einem die Zahl erklärt wird

    Ein Großteil der Angst dreht sich um die Kernel-Version. Linux 7.0 sieht auf dem Papier nach einem gewaltigen Sprung aus, nach der Art Versionsnummer, bei der alte Treiber sich weinend in eine Ecke verkriechen. Aber viele Nutzer versuchen, die Stimmung zu beruhigen. Das ruhige Lager weist immer wieder darauf hin, dass große Linux-Versionssprünge nicht zwangsläufig bedeuten, dass sich der Boden unter allen verschoben hat. Wie ein Kommentator es ausdrückte: „7.0 ist einfach nur eine Zahl." Ein anderer sagte, der Sprung diene vor allem dazu, die Minor-Versionsnummern nicht albern werden zu lassen, nicht irgendeiner dramatischen Neuschreibung der Realität.

    Diese Beruhigung zählt, weil frühe Berichte von vielen Nutzern auf die beste Art langweilig sind. Leute, die VMs, LXCs, Windows-Gäste, Linux-Gäste und gewöhnliches GPU-Passthrough betreiben, sagen, der Umstieg auf Kernel 7.0 sei ereignislos verlaufen. Eine Person nannte es „eine Nichtigkeit im guten Sinne", was so ziemlich das höchste Kompliment ist, das ein Infrastruktur-Upgrade bekommen kann. Eine andere hatte bereits mehrere Hosts auf 9.1.9 mit Kernel 7.0.0-3 umgestellt und keinerlei Probleme festgestellt, selbst mit GPU-Passthrough. In dieser Welt sind keine Neuigkeiten nicht nur gute Neuigkeiten. Es ist der Traum.

    Trotzdem entspannt sich niemand mit einem ernsthaften Homelab sofort, nur weil er „bei mir hat's funktioniert" hört. Das Gefährliche versteckt sich oft in den Randfällen. Ein System bootet einwandfrei. Die Dashboards sehen zufrieden aus. Dann, ein paar Stunden später, findet ein Scrub, ein Treiber-Rebuild oder ein Job mit hohem I/O den Riss. Ein Nutzer beschrieb ein früheres Upgrade, bei dem hohe Laufwerksaktivität eine Katastrophe auslöste, die sich zu ZFS-Korruption auswuchs. Backups retteten die Situation, aber die Wiederherstellung dauerte Wochen. Das ist die Art von Geschichte, die sich im Gedächtnis der Community festsetzt. Sie macht aus jedem „wird schon passen" ein „wird schon passen, aber ich halte mir das Wochenende frei".

    Bei GPU-Passthrough wird das Selbstvertrauen seltsam

    GPU-Passthrough ist das emotionale Zentrum dieser gesamten Diskussion. Nutzer von vollständigem Passthrough klingen größtenteils entspannt. Einige berichteten, ihre Maschinen liefen auf Kernel 7 problemlos, einschließlich Systeme mit Grafik-Passthrough, vollständigem Intel-NIC-Passthrough und sogar SATA-Controller-Passthrough. Jemand mit X99 berichtete, alles funktioniere gut, bis auf eine NIC auf e1000e-Basis, der es nicht so gut ging. Ein anderer sagte, vollständiges Passthrough „funktioniert auf 7". Für diese Setups wirkt das Upgrade weniger wie eine Klippe und mehr wie ein normales Wartungsfenster mit besseren Snacks.

    vGPU-Nutzer leben dagegen in einem ganz anderen Film. Ein Kommentator brachte es direkt auf den Punkt: „Aber vollständiges Passthrough oder vGPU? vGPU ist deutlich schwieriger." Das ist die Kluft. Vollständiges Passthrough kann schon empfindlich sein, aber vGPU fügt eine Schicht Treiber-Magie hinzu, die sich anfühlt, als sei sie nur ein Kernel-Update von einem Wochenendprojekt entfernt. Die ursprüngliche Sorge kam von einem Arrow-Lake-vGPU-Setup, und andere bestätigten dieselbe Anspannung. Eine Person mit Meteor Lake sagte, sie würde sich einen ganzen Tag für Troubleshooting freihalten, weil sich die Plattform vergessen anfühlt. Das ist keine Panik. Das ist gelernte Vorsicht.

    Es gab auch Erfolgsgeschichten. Ein Arrow-Lake-Nutzer sagte, vGPU habe nach dem Upgrade keine Probleme gehabt, mit „buchstäblich keinem spürbaren Unterschied". Ein anderer erwähnte, dass er den neuesten i915-SR-IOV-DKMS-Treiber brauchte, weil der ältere Treiber aus der 6.x-Ära virtuelle Funktionen nicht richtig unterstützte oder fehlerhaftes Verhalten zeigte. Das ist die Proxmox-Erfahrung in einem Satz: Es kann vollkommen reibungslos laufen, außer Ihre genaue Kombination aus Hardware, Treiberzweig und Kernel entscheidet, dass Sie jetzt an der Reihe sind. Die Nutzer, die abwarten, sind nicht dramatisch. Sie schützen ihr Wochenende, ihren Storage und vielleicht ihren Verstand.

    ZFS ist das Feature, das alle wollen, und das Risiko, vor dem alle sich fürchten

    Das Versprechen von besserem ZFS ist einer der Hauptgründe, warum Leute überhaupt zu 9.2 tendieren. Storage-Verbesserungen sind nicht auffällig im Sinne von Consumer-Tech, aber für Proxmox-Nutzer ist Storage das ganze Spiel. Besseres Metadaten-Handling, schnelleres Resilvering, geschmeidigeres asynchrones I/O und neueres OpenZFS-Verhalten klingen großartig, wenn man auf einen Stapel Platten starrt, der Jahre angesammelter Daten und schlechter Entscheidungen repräsentiert. Eine Person fragte unverblümt: „Moment, es gibt ZFS-Änderungen? Wo?" Diese Frage kam wahrscheinlich halb aus Neugier und halb aus dem Instinkt, jede Fußnote zu finden, bevor man an die Produktivumgebung geht.

    Der Haken ist, dass ZFS-Upgrades zwei Ebenen haben: den Software-Stack und die Pool-Features auf der Platte. Eine neuere ZFS-Version bedeutet nicht immer, dass sich Ihr Pool-Format automatisch ändert. Jemand erinnerte den Thread daran, dass ein zpool upgrade ein eigener, expliziter Schritt ist. Genau dieses kleine Detail ist der Grund, warum Leute nervös werden. Es gibt das Upgrade, von dem Sie glauben, es durchzuführen, und dann gibt es das Upgrade, das Sie versehentlich starten, weil Sie zu schnell durchgeklickt oder missverstanden haben, was sich geändert hat. Bei Storage kann Letzteres wehtun.

    Die vorsichtigen Stimmen sind nicht gegen das Upgrade. Sie sind gegen Überraschungen. Ein Nutzer riet, vorher ein Backup mit Proxmox Backup Server zu machen, was offensichtlich klingt, bis man sich daran erinnert, wie viele Heimserver jahrelang mit Backups laufen, die eher Bauchgefühl sind als getestete Wiederherstellungspläne. Ein anderer gab zu, er sollte gute Backups haben, teste sie aber normalerweise nicht im Voraus. Dieser Satz sagt mehr über reale Infrastruktur aus als jeder polierte Guide es je könnte. Die Leute wissen, was sie tun sollten. Das Upgrade-Fenster ist der Ort, an dem Theorie auf die hässlichen kleinen Kompromisse des Alltags trifft.

    Die versteckten Bösewichte: NIC-Namen, Audit-Spam und Treiber

    Die auffälligen Sorgen bekommen die ganze Aufmerksamkeit, aber die kleinen Dinge sind es vielleicht, die Leute wirklich zu Fall bringen. Ein Nutzer warnte, dass Audit-Meldungen während des Upgrades Bildschirm-Prompts fast sofort wegscrollen können, wenn sie nicht deaktiviert werden. Ein anderer antwortete, genau diese Meldungen hätten ihn beim letzten Mal ruiniert. Das ist klassischer Admin-Schmerz: kein katastrophaler Kernel-Bug, kein rauchendes Mainboard, nur genug Terminal-Rauschen, um das zu begraben, was man eigentlich lesen musste. Infrastruktur scheitert selten mit filmreifem Timing. Manchmal scheitert sie, weil der Prompt verschwand, bevor man ihn gesehen hat.

    Netzwerkschnittstellen sind eine weitere stille Falle. Jemand warnte, dass das Upgrade NICs umbenennen kann, wenn deren Namen nicht fixiert sind – was nur lustig ist, wenn die Maschine in Armreichweite steht. Remote-Admins kennen das besondere Grauen, das entsteht, wenn man merkt, dass der Server wahrscheinlich sauber gebootet hat, aber die Schnittstelle umbenannt hat, über die er mit der Welt spricht. Eine Antwort war schlicht: „NIC-Namen haben mich erwischt." Da braucht es keine Poesie. Das ist die ganze Wunde.

    Dann sind da noch die Treiber. Bei einem Nutzer mussten proprietäre Mellanox-Treiber aktualisiert werden. Bei einem anderen Passthrough-Setup ließen sich ältere Nvidia-Treiber nicht kompilieren. Probleme mit Intel e1000 und e1000e tauchten immer wieder auf, wobei manche Nutzer harte Lockups, gezogene Kabel, Resets von Managed-Switch-Ports und Workarounds mit Offload-Einstellungen oder dem Tausch gegen eine i226-Karte beschrieben. Eine Person mit Kernel 7.0.2-2 sagte, sie habe immer noch einen e1000-Kernel-Crash, also kaufen längst nicht alle die „jetzt behoben"-Geschichte ab. Deshalb lesen Leute nicht einfach nur Release Notes. Sie lesen die Narben anderer Leute.

    Manche upgraden jetzt, manche warten ab, und beide Seiten ergeben Sinn

    Die Fraktion der Früh-Upgrader hat gute Argumente. Manche Nutzer sind bereits ohne Drama auf Kernel 7.0 umgestiegen. VMs funktionieren. LXCs funktionieren. GPU-Passthrough funktioniert. Mini-PCs funktionieren. Mehrere Hosts funktionieren. Für sie beginnt sich Abwarten wie Aberglaube anzufühlen, besonders wenn Proxmox 8 eine sichtbare, nicht endlose Support-Laufzeit hat. Eine Person wies darauf hin, dass der Umstieg auf Proxmox 9 teilweise von der zugrunde liegenden Debian-Basis und dem Sicherheits-Zeitplan getrieben wird, nicht nur vom Hunger nach neuen Funktionen. Irgendwann wird Stillstehen selbst zu einer Art Risiko.

    Die Abwarten-Fraktion hat ebenfalls gute Argumente. Eine Person sagte, sie bleibe bis kurz vor August auf 8.4.1, weil es keinen dringenden Grund zum Wechseln gebe. Eine andere rollte nach Hardware-Änderungen, die GPU-Passthrough kaputt gemacht hatten, zurück auf 8.4 und sagte, sie warte, bis das Upgrade breitere Zustimmung verdient habe. Jemand anderes brachte es noch einfacher auf den Punkt: „Wenn du nicht upgraden musst, überleg dir, es nicht zu tun." Dieser Rat klingt vielleicht langweilig, aber langweiliger Rat ist oft das, was Systeme am Leben hält.

    Es gibt auch eine dritte Gruppe: die Leute, die aufgeregt sind, aber einen Plan machen. Sie beobachten Backup Server 4.2, vermuten, dass VE 9.2 bald folgen könnte, prüfen die Roadmap, lesen Treiberberichte und entscheiden, ob sie Kernel fixieren, Backups testen oder den Umstieg zuerst auf weniger wichtigen Nodes erproben sollen. Das ist wahrscheinlich die gesündeste Haltung. Keine Angst. Kein blindes Vertrauen. Einfach Respekt vor der Tatsache, dass ein Hypervisor-Upgrade nie nur ein Hypervisor-Upgrade ist. Es ist Storage, Netzwerk, Treiber, Firmware, Gäste und die chaotische Hardware-Lotterie darunter.

    Das eigentliche Upgrade ist Vertrauen

    Was diesen 9.2-Moment interessant macht, ist nicht nur die Software. Es ist der emotionale Vertrag, den Proxmox mit seinen Nutzern hat. Diese Leute sind bereit, ernsthafte Workloads auf einer Plattform zu betreiben, die sie oft allein verwalten, spät nachts, mit einem Browser-Tab offen für die Dokumentation und einem weiteren voller Fehler anderer Leute. Sie lieben die Kontrolle. Sie lieben die Power. Sie lieben, dass sich ein Homelab wie ein winziges Rechenzentrum anfühlen kann. Aber sie wissen auch, dass die Rechnung fällig wird, sobald der Upgrade-Button erscheint.

    Also ja, die Leute freuen sich auf Proxmox VE 9.2. Sie wollen besseres ZFS. Sie wollen neuere Kernel. Sie wollen saubereres mobiles Management, frischere Container-Funktionen und all die stillen Verbesserungen, die die Plattform schärfer wirken lassen. Aber die Vorfreude ist vorsichtig. Es ist die Art, die mit einem im Hintergrund laufenden Backup-Job und der gedanklichen Notiz kommt, nach dem Reboot die IOMMU-Gruppen zu prüfen.

    Das beste Zeichen für 9.2 ist, dass viele frühe Kernel-7.0-Geschichten langweilig sind. Langweilig ist hier schön. Langweilig heißt: Die VM startet, die NIC behält ihren Namen, das Array bleibt gesund, die GPU taucht auf, und niemand verbringt den Samstag damit, Treiber aus dem Quellcode neu zu bauen. Aber die Community liegt nicht falsch damit, nervös zu sein. Proxmox-Nutzer haben auf die harte Tour gelernt, dass „funktioniert bei mir" nützlich ist, aber nicht universell gilt. Das Upgrade mag reibungslos verlaufen. Es mag sogar großartig sein. Trotzdem lohnt es sich, vor dem Update-Drücken die unglamouröseste Sache der Tech-Welt zu tun: das Backup machen, die Wiederherstellung testen und sich einen Weg zurück offenhalten.