Von PVE 5 zu 9: Was passiert, wenn Legacy-Infrastruktur nicht loslassen will

Wer die Infrastruktur eines anderen erbt, lernt eine ganz eigene Sorte Stress kennen.

Mit sauber dokumentierten Umgebungen oder der "das migrieren wir nächstes Quartal"-Sorte hat das wenig zu tun. Ich rede von dem tief eingelebten, geschäftskritischen, leicht verstaubten Stack, der seit Jahren vor sich hin läuft, weil eine Person genau wusste, wie er funktioniert. Und diese Person ist jetzt nicht mehr da.

In genau dieser Lage steckt ein kleines Unternehmen, das immer noch auf Proxmox VE 5.4-15 läuft, einer Version, die sich eher wie eine Zeitkapsel anfühlt als wie Software. Jetzt muss es springen, und zwar gleich über mehrere Versionen hinweg bis zu 9.

Wenn "es funktioniert noch" nicht reicht

Auf dem Papier war das Setup überschaubar: zwei Nodes, eine Handvoll VMs und ein NAS für Backups, nichts Exotisches.

Ein Node humpelte bereits auf 8.x vor sich hin, bevor seine Laufwerke anfingen auszufallen. Er wurde durch einen neuen Supermicro-Microserver mit sauberer Installation und frischem Proxmox 9 ersetzt, und das lief tatsächlich … glatt. Backups über Proxmox Backup Server funktionierten, und die Migration vom sterbenden Node weg ging gut. So weit, so gut.

Bleibt die alte PVE-5-Kiste, und auf dieser Maschine leben die echten Gespenster.

Das NAS, das erstickt

Die verbleibenden geschäftskritischen VMs zu sichern sollte einfach sein, zumindest theoretisch. In der Praxis legen Backups von PVE 5 zum NAS dieses fast lahm.

Das NAS ist eine TerraMaster-Box in RAID 5 mit einer einzelnen 1-Gbit-NIC. Die VMs laufen nicht darauf, es dient nur als gemountetes Backup-Ziel. Sobald aber ein Backup-Job startet, kriecht alles. Das NAS kommt ins Schwitzen, das Netzwerk ächzt, und man hat das Gefühl, die Box mit jedem Job einen Schritt näher an die Rente zu schieben.

Das NAS steht zwar schon auf der Upgrade-Liste, so weit ist es aber noch nicht. Was also tun, wenn ausgerechnet der Schutz der eigenen Daten den Storage zerstören könnte?

Die Antwort der Community war erfrischend pragmatisch: langsamer machen. Rate Limiting ist nicht spektakulär und fühlt sich nicht wie eine "große Lösung" an. Wer aber bwlimit in /etc/vzdump.conf setzt und die Übertragungsgeschwindigkeit deckelt, sagen wir auf 50 MB/s, sorgt womöglich schon dafür, dass das NAS nicht unter dem Schreibdruck ertrinkt. Auf der PBS-Seite funktioniert dieselbe Idee mit Traffic-Control-Regeln.

Glamourös oder modern ist das nicht, aber es funktioniert. Manchmal hilft Zurückhaltung mehr als schnellere Hardware.

Die Versuchung, Schritte zu überspringen

Im Hinterkopf meldet sich immer der Gedanke, einfach an Ort und Stelle zu aktualisieren: 5 auf 6, 6 auf 7, 7 auf 8, 8 auf 9. Das wären langsame, methodische, unterstützte Pfade.

Nur ist das hier ein Unternehmen und kein Lab, 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 läuft unter Windows 7, ohne Internetzugang, und trägt einen Kernservice. Sie ist auf die furchteinflößendste Art unantastbar. Die anderen laufen unter Windows 10, leicht vernetzt, aber ebenfalls kritisch.

Gehen die kaputt, wartet kein Neuinstallations-Skript in einem Git-Repo. Dokumentation gibt es keine, nur Angst. Deshalb fühlt sich der Sprung von 5 auf 9 weniger wie ein Upgrade an und mehr wie eine Operation am offenen Herzen.

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.

Ein Fehler ist das nicht, alles bootet. Die Uhr tickt aber.

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, bloß virtuelle Hardware unter der Haube. In Wirklichkeit ist es ein Plattformwechsel.

Der Wechsel von i440FX auf Q35 ist mehr als ein umgeschaltetes Dropdown. Er kann eine Neuinitialisierung von Geräten auslösen, mit neuen virtuellen NICs und neuer PCI-Topologie, sodass Windows womöglich komplett neue Hardware sieht. Das kann bedeuten:

• Möglicherweise neue IP-Adressen
• Treiber-Durcheinander
• Aktivierungsprobleme
• Diese schreckliche "Gerätetreibersoftware wird installiert …"-Pause

Bei einer Lab-VM ist das kein Problem. Bei einer Windows-7-Kiste mit geschäftskritischer Kernsoftware, die niemand anfassen will, wird daraus ein Neustart mit schweißnassen Händen.

Erfahrene Admins rieten unverblümt: Behandeln Sie es wie neue Hardware. Planen Sie eine erneute Geräteerkennung ein, rechnen Sie damit, das Netzwerk neu konfigurieren zu müssen, und gehen Sie nicht davon aus, dass der Wechsel unbemerkt bleibt. Panik ist trotzdem nicht angebracht. In den meisten Fällen funktioniert es, es verlangt nur bewusstes Vorgehen.

Eine feste 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, und der Aufwand lohnt sich nicht. Wer noch auf 5 ist, sollte auf einen hybriden Frankenstein-Cluster verzichten und stattdessen plattmachen und neu aufsetzen. Also frisch aufbauen, Backups wiederherstellen, die virtuelle Hardware im modernen Release aktualisieren und danach die Guest Tools.

Dieser saubere Schnitt ist oft weniger riskant, als sich mit inkrementellen Patches durch ein halbes Jahrzehnt an Änderungen zu hangeln.

Das "Kopier doch einfach die Disk"-Argument

Irgendjemand schlägt das immer vor, und ganz falsch liegt er damit nicht. Ist die VM-Disk eine qcow2-Datei, kopiert man sie mit rsync. Bei LVM nimmt man dd und ncat. Dann herunterfahren, kopieren und die Konfiguration aus /etc/pve/ neu erstellen.

Technisch ist das solide, emotional furchteinflößend. Ein Disk-Image zu kopieren fühlt sich an, als würde man den "offiziellen" Pfad umgehen, eher nach Klebeband, auch wenn es das gar nicht ist.

Proxmox-VMs bestehen größtenteils nur aus Disk-Dateien und Konfigurationstext, und nirgendwo steckt eine magische Datenbank. Wer versteht, was er da kopiert, geht einen völlig legitimen Weg. Entscheidend ist die Downtime: Die VM muss offline sein, halbe Sachen gibt es hier nicht.

Bei vielen Migrationen ist diese direkte Disk-Kopie außerdem schneller und schonender für fragilen Storage als wiederholte Backup-Zyklen.

Es gibt auch den Veeam-Weg

Für Windows-VMs kam noch eine Option auf: sie wie physische Maschinen behandeln. Tools wie Veeam Backup & Replication können eine Windows-VM auf OS-Ebene sichern und in einer neuen Umgebung wiederherstellen, womit der Hypervisor-Sprung aus dem Spiel ist.

Das ist attraktiv, wenn sich die Versionslücke beim Hypervisor gefährlich anfühlt. Allerdings bringt auch dieser Weg eine weitere Schicht mit, ein zusätzliches Tool und eine zusätzliche Abhängigkeit. Manchmal ist das Einfachere tatsächlich das Sicherere.

Das emotionale Gewicht von Legacy-Systemen

Ein Detail dieser Geschichte wiegt schwerer als jedes Bandbreitenlimit oder jede Machine-Type-Flag: Die Umgebung gehörte jemandem, dem es sehr wichtig war, sie am Laufen zu halten, und jetzt trägt jemand anderes diese Verantwortung weiter.

Das verändert den Umgang mit Risiko. Man will nicht derjenige sein, der alles in die Downtime "modernisiert" hat, und schon gar nicht die eine Windows-7-VM mit der uralten Individual-App kaputtmachen, die niemand versteht.

Also bewegt man sich vorsichtig, testet Backups wiederholt, verifiziert PBS-Jobs und 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

Legacy-Infrastruktur versagt selten auf einen Schlag, sie verschlechtert sich in Schichten. Erst sind es die Laufwerke, dann die Warnungen, dann die nicht mehr unterstützten Versionen und schließlich die Backup-Engpässe. Jede Schicht flüstert dasselbe: "Du hättest früher aktualisieren sollen."

Kleine Unternehmen haben aber nicht immer Upgrade-Budgets, Ersatzhardware oder Downtime-Fenster. Deshalb überleben solche Umgebungen länger, als sie sollten, und wenn das Upgrade endlich kommt, ist es ein Sprung über Jahre.

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. Riskant ist dabei weniger die Software als der unbekannte Individual-Workload in diesen Windows-VMs.

Das Playbook, das sich daraus ergibt

Aufs Wesentliche reduziert sieht die Strategie so aus:

1. Verifizierte Backups über Proxmox Backup Server sicherstellen.
2. Backups per Rate Limiting drosseln, um alte NAS-Hardware nicht zu überlasten.
3. Kein Clustering gemischter Hauptversionen.
4. Auf frischen 8.x/9.x-Nodes wiederherstellen.
5. Virtuelle Hardware bewusst aktualisieren.
6. Testen, bevor man Machine Types anfasst.
7. Den Wechsel von i440FX zu Q35 als Plattformmigration behandeln und nicht als kosmetische Änderung.

Revolutionär ist daran nichts, es ist einfach diszipliniertes Vorgehen. Und diese Disziplin hält kleine Unternehmen bei solchen Übergängen am Leben.

Und diese Windows-7-Kiste?

Sie ist immer noch da, läuft immer noch und ist vom Internet isoliert wie ein Museumsexponat hinter Glas.

Irgendwann muss sie umziehen, in Rente gehen oder innerhalb einer anderen VM virtualisiert werden, als eine Art digitale Matroschka. Vorerst muss sie nur den Hypervisor-Sprung überleben, und ehrlich gesagt reicht das.

Modernisierung kann auch bedeuten, das weiterzutragen, was bereits funktioniert, statt dem neuesten Release hinterherzujagen: vorsichtig, respektvoll und ohne die Dinge kaputtzumachen, die dafür sorgen, dass die Lichter an bleiben.