Von PVE 5 zu 9: Was passiert, wenn Legacy-Infrastruktur nicht loslassen will
Es gibt eine ganz besondere Art von Stress, die erst auftaucht, wenn man die Infrastruktur eines anderen erbt.
Nicht die saubere, gut dokumentierte Art. Nicht die "das migrieren wir nächstes Quartal"-Art. Ich rede von dem zutiefst eingelebten, geschäftskritischen, leicht verstaubten Stack, der seit Jahren vor sich hin läuft, weil eine Person genau wusste, wie er funktioniert - und die ist jetzt nicht mehr da.
Das ist die Situation bei einem kleinen Unternehmen, das immer noch auf Proxmox VE 5.4-15 läuft. Eine Version, die sich weniger wie Software anfühlt und mehr wie eine Zeitkapsel.
Und jetzt muss es springen - nicht eine Version weiter - sondern den ganzen Weg bis zu 9.
Wenn "es funktioniert noch" nicht reicht
Auf dem Papier war das Setup nicht gewaltig. Zwei Nodes. Eine Handvoll VMs. Ein NAS für Backups. Nichts Exotisches.
Ein Node humpelte bereits auf 8.x vor sich hin, bevor seine Laufwerke anfingen auszufallen. Der wurde durch einen neuen Supermicro-Microserver ersetzt. Saubere Installation. Frisches Proxmox 9. Es lief tatsächlich … glatt. Backups über Proxmox Backup Server funktionierten. Die Migration vom sterbenden Node weg lief gut.
So weit, so gut.
Aber dann ist da noch die alte PVE-5-Kiste.
Auf dieser Maschine leben die echten Gespenster.
Das NAS, das erstickt
Die verbleibenden geschäftskritischen VMs zu sichern sollte einfach sein. Theoretisch.
In der Praxis? Backups von PVE 5 zum NAS zu schicken, legt es fast lahm.
Das NAS ist eine TerraMaster-Box in RAID 5 mit einer einzelnen 1-Gbit-NIC. Es betreibt nicht die VMs selbst - es dient nur als gemountetes Backup-Ziel. Aber sobald ein Backup-Job startet, verlangsamt sich alles zum Kriechtempo. Das NAS kommt ins Schwitzen. Das Netzwerk ächzt. Es fühlt sich an, als würde man es mit jedem Job einen Schritt näher an die Rente schieben.
Und hier liegt die Spannung: Das NAS steht bereits auf der Upgrade-Liste. Aber so weit ist es noch nicht.
Was also tun, wenn ausgerechnet der Akt, die eigenen Daten zu schützen, das sein könnte, was den Storage zerstört?
Die Antwort der Community war erfrischend pragmatisch: verlangsamen.
Rate Limiting ist nicht spektakulär. Es fühlt sich nicht wie eine "große Lösung" an. Aber bwlimit in /etc/vzdump.conf zu setzen, um die Übertragungsgeschwindigkeit zu deckeln - sagen wir auf 50 MB/s -, kann genügen, damit das NAS nicht unter dem Schreibdruck ertrinkt. Dieselbe Idee auf der PBS-Seite mithilfe von Traffic-Control-Regeln.
Es ist nicht glamourös. Es ist nicht modern. Aber es funktioniert.
Und manchmal ist die richtige Antwort nicht schnellere Hardware. Es ist Zurückhaltung.
Die Versuchung, Schritte zu überspringen
Da ist immer dieser Gedanke im Hinterkopf:
Was, wenn wir einfach an Ort und Stelle aktualisieren? 5 auf 6. 6 auf 7. 7 auf 8. 8 auf 9.
Langsame, methodische, unterstützte Pfade.
Nur ist das hier kein Lab. Das ist ein Unternehmen. Und die betroffenen VMs laufen mit uralter Individualsoftware, von der niemand so genau weiß, wie man sie von Grund auf neu bauen würde.
Eine davon ist Windows 7. Kein Internetzugang. Kernservice. Unantastbar auf die furchteinflößendste Art.
Die anderen laufen unter Windows 10, leicht vernetzt, aber immer noch kritisch.
Wenn die kaputtgehen, wartet kein Neuinstallations-Skript in einem Git-Repo. Es gibt keine Dokumentation. Es gibt nur Angst.
Und genau das lässt diesen Sprung von 5 auf 9 weniger wie ein Upgrade und mehr wie eine Operation am offenen Herzen wirken.
Die i440FX-Warnung, die nicht verschwindet
Nach der Migration einiger VMs auf den Proxmox-9-Node erscheint eine neue Warnung:
Machine type 'pc-i440fx-5.1' is deprecated. Current machine version is subject to deletion.
Es ist kein Fehler. Alles bootet.
Aber die Uhr tickt.
Der alte i440FX-Maschinentyp emuliert einen veralteten, PCI-basierten Chipsatz. Modernes Proxmox bevorzugt Q35, das eine PCIe-basierte Plattform emuliert. Auf dem Papier klingt das nach einer Kleinigkeit - nur virtuelle Hardware unter der Haube.
In Wirklichkeit? Es ist ein Plattformwechsel.
Von i440FX auf Q35 zu wechseln ist nicht einfach ein Dropdown umschalten. Es kann eine Neuinitialisierung von Geräten auslösen. Neue virtuelle NICs. Neue PCI-Topologie. Windows sieht möglicherweise komplett neue Hardware.
Das bedeutet:
- Möglicherweise neue IP-Adressen
- Treiber-Durcheinander
- Aktivierungsprobleme
- Diese schreckliche "Gerätetreibersoftware wird installiert …"-Pause
Bei einer Lab-VM, kein Problem. Bei einer Windows-7-Kiste, auf der geschäftskritische Kernsoftware läuft, die niemand anfassen will?
Das ist ein Neustart mit schweißnassen Händen.
Der Rat erfahrener Admins war unverblümt: Behandeln Sie es wie neue Hardware. Planen Sie mit einer erneuten Geräteerkennung. Rechnen Sie damit, das Netzwerk neu konfigurieren zu müssen. Gehen Sie nicht davon aus, dass es unsichtbar bleibt.
Aber auch - keine Panik.
In den meisten Fällen funktioniert es. Es erfordert nur bewusstes Vorgehen.
Die stille Regel: Nicht generationsübergreifend clustern
Ein Ratschlag stach klar heraus:
5.x nicht mit 8.x oder 9.x clustern.
Allein die API-Unterschiede können Kopfschmerzen bereiten. Es lohnt sich nicht. Wer noch auf 5 ist, sollte nicht versuchen, einen hybriden Frankenstein-Cluster zu bauen.
Stattdessen? Plattmachen und neu aufsetzen.
Frisch aufbauen. Backups wiederherstellen. Virtuelle Hardware aktualisieren, nachdem man in einem modernen Release gelandet ist. Dann die Guest Tools aktualisieren.
Dieser saubere Schnitt ist oft weniger riskant als inkrementelles Patchen durch ein halbes Jahrzehnt an Änderungen.
Das "Kopier doch einfach die Disk"-Argument
Es gibt immer jemanden, der das vorschlägt - und der liegt nicht falsch.
Wenn die VM-Disk eine qcow2-Datei ist? Mit rsync kopieren.
Wenn es LVM ist? dd und ncat.
Herunterfahren. Kopieren. Konfiguration aus /etc/pve/ neu erstellen.
Technisch solide.
Emotional furchteinflößend.
Denn ein Disk-Image zu kopieren fühlt sich an, als würde man den "offiziellen" Pfad umgehen. Es fühlt sich nach Klebeband an, selbst wenn es das nicht ist.
Aber hier ist der Punkt: Proxmox-VMs sind größtenteils nur Disk-Dateien und Konfigurationstext. Es gibt keine magische Datenbank, die irgendwo versteckt ist. Wenn man versteht, was man da kopiert, ist das völlig legitim.
Der Schlüssel ist Downtime. Die VM muss offline sein. Keine halben Sachen.
Und bei vielen Migrationen ist diese direkte Disk-Kopie schneller und schonender für fragilen Storage als wiederholte Backup-Zyklen.
Es gibt auch den Veeam-Weg
Für Windows-VMs kam eine weitere Option auf: Sie wie physische Maschinen behandeln.
Tools wie Veeam Backup & Replication können eine Windows-VM auf OS-Ebene sichern und in eine neue Umgebung wiederherstellen. Das abstrahiert den Hypervisor-Sprung weg.
Das ist attraktiv, wenn sich die Versionslücke des Hypervisors gefährlich anfühlt.
Aber auch das führt eine weitere Schicht ein. Ein weiteres Tool. Eine weitere Abhängigkeit.
Manchmal ist einfacher wirklich sicherer.
Das emotionale Gewicht von Legacy-Systemen
Es gibt ein Detail in dieser Geschichte, das wichtiger ist als jedes Bandbreitenlimit oder jede Machine-Type-Flag:
Diese Umgebung gehörte jemandem, dem es zutiefst wichtig war, sie am Laufen zu halten.
Und jetzt trägt jemand anderes diese Verantwortung weiter.
Das verändert, wie man an Risiko herangeht.
Man will nicht die Person sein, die alles in Richtung Downtime "modernisiert" hat. Man will nicht die eine Windows-7-VM kaputtmachen, auf der eine uralte Individual-App läuft, die niemand versteht.
Also bewegt man sich vorsichtig. Man testet Backups wiederholt. Man verifiziert PBS-Jobs. Man fragt die Community, bevor man Machine Types anfasst.
Man respektiert das System, auch wenn es veraltet ist.
Was tatsächlich passiert, wenn Legacy nicht loslassen will
Hier die Wahrheit: Legacy-Infrastruktur versagt nicht alles auf einmal.
Sie verschlechtert sich in Schichten.
Zuerst sind es die Laufwerke. Dann die Warnungen. Dann die nicht mehr unterstützten Versionen. Dann die Backup-Engpässe.
Jede Schicht flüstert dasselbe: "Du hättest früher aktualisieren sollen."
Aber kleine Unternehmen haben nicht immer Upgrade-Budgets. Oder Ersatzhardware. Oder Downtime-Fenster.
Also überleben Umgebungen wie diese länger, als sie sollten. Und wenn das Upgrade endlich kommt, ist es ein Sprung über Jahre hinweg.
Die gute Nachricht?
Proxmox ist über Generationen hinweg überraschend widerstandsfähig. Mit ordentlichen Backups, Offline-Disk-Kopien und sorgfältigen Hardware-Übergängen ist der Sprung von 5 auf 9 machbar.
Der riskante Teil ist nicht die Software.
Es ist der unbekannte Individual-Workload innerhalb dieser Windows-VMs.
Das Playbook, das sich daraus ergibt
Reduziert man das auf das Wesentliche, sieht die Strategie so aus:
- Verifizierte Backups über Proxmox Backup Server sicherstellen.
- Backups per Rate Limiting drosseln, um alte NAS-Hardware nicht zu überlasten.
- Kein Clustering gemischter Hauptversionen.
- Auf frischen 8.x/9.x-Nodes wiederherstellen.
- Virtuelle Hardware bewusst aktualisieren.
- Testen, bevor man Machine Types anfasst.
- Den Wechsel von i440FX zu Q35 als Plattformmigration behandeln, nicht als kosmetische Änderung.
Nichts Revolutionäres. Nur diszipliniertes Vorgehen.
Aber genau diese Disziplin hält kleine Unternehmen bei Übergängen wie diesem am Leben.
Und diese Windows-7-Kiste?
Sie ist immer noch da.
Läuft immer noch.
Immer noch vom Internet isoliert wie ein Museumsexponat hinter Glas.
Irgendwann muss sie umziehen. Oder in Rente gehen. Oder innerhalb einer anderen VM virtualisiert werden, wie eine Art digitale Matroschka.
Aber vorerst muss sie nur den Hypervisor-Sprung überleben.
Und ehrlich gesagt? Das reicht.
Denn manchmal geht es bei Modernisierung nicht darum, dem neuesten Release hinterherzujagen.
Es geht darum, das weiterzutragen, was bereits funktioniert - vorsichtig, respektvoll und ohne die Dinge kaputtzumachen, die dafür sorgen, dass die Lichter an bleiben.