Die Migration von 200+ VMs zu Proxmox ist kein Compute-Problem — es ist ein Netzwerkproblem

Auf dem Papier klingt es wie eine Compute-Geschichte, Hunderte virtuelle Maschinen von VMware zu Proxmox zu verschieben. Storage-Durchsatz. CPU-Kompatibilität. Disk-Formate. Import-Tools. Checklisten. Fortschrittsbalken.

In der Praxis ist das nicht das, was den Leuten nachts den Schlaf raubt.

Was tatsächlich den kalten Schweiß auslöst, ist das Netzwerk. Nicht die saubere, aufgezeichnete Version, die in einer Visio-Datei von 2019 lebt, sondern die echte. Die unordentliche. Die mit fest codierten IPs, vergessenen Firewall-Regeln, MAC-basierten Lizenzen, stillen Datenbankabhängigkeiten und Traffic-Flows, an deren Einrichtung sich niemand mehr erinnert.

Wenn Sie 200-plus VMs von VMware ESXi wegmigrieren, ist selten der Hypervisor-Wechsel selbst das, was etwas kaputt macht. Es ist alles, was drumherum hängt.

Der Import funktioniert. Die Apps nicht.

Fast jeder, der das im großen Maßstab gemacht hat, sagt eine Version desselben Satzes: Der Proxmox-Import-Assistent macht seinen Job. Disks kommen rüber. Maschinen booten. CPUs laufen. Der Speicher sieht gut aus.

Dann scheitert etwas Subtiles.

Eine Anwendung startet, kann aber nicht mit ihrer Datenbank sprechen. Ein Reporting-Job läuft, wird aber nie fertig. Ein Legacy-Service wirft keinen Fehler — er hört einfach still auf, nützliche Arbeit zu leisten. Das Monitoring schlägt Stunden später an, oder schlimmer: Ein Nutzer bemerkt es erst Tage, nachdem das Migrationsfenster geschlossen wurde.

Das ist die Gefahrenzone. Stille Störungen sind schwieriger als laute Ausfälle. Ein lauter Ausfall gibt Ihnen einen Ansatzpunkt.

Und fast jeder dieser Ausfälle lässt sich bis zum Netzwerk zurückverfolgen.

Fest codierte Realität gewinnt immer

Theoretisch sollte alles abstrahiert sein. DNS statt IPs. Service Discovery statt statischer Configs. Firewall-Regeln dokumentiert und beabsichtigt.

In der Realität sind viele Umgebungen über ein Jahrzehnt oder länger organisch gewachsen. Jemand hat eine IP fest codiert, weil sie „vorübergehend" sein sollte. Jemand hat eine App direkt mit einer Datenbank verknüpft, weil das schneller war. Jemand hat eine Hairpin-Firewall-Regel eingerichtet, um ein seltsames Problem zu lösen, und sie dann vergessen.

Diese Entscheidungen tauchen nicht auf, wenn Sie eine VM exportieren. Sie zeigen sich erst, wenn der Traffic nicht mehr so fließt wie zuvor.

Deshalb reden so viele erfahrene Admins nicht über CPU-Flags oder Disk-Formate, wenn man sie fragt, wie man im großen Maßstab migriert. Sie reden über Traffic-Monitoring, VLANs, ARP-Tabellen und MAC-Adressen.

Wenn Sie den Traffic nicht sehen, kennen Sie die App nicht

Einer der häufigsten Ratschläge von Leuten, die bereits große Migrationen durchgeführt haben, ist unverblümt: Das Netzwerk lügt nicht.

Bevor Sie irgendetwas verschieben, wollen Sie sehen, wer mit wem spricht. Nicht wer Ihrer Meinung nach sprechen sollte — sondern wer es tatsächlich tut.

Das bedeutet normalerweise eine Kombination aus:

• Firewall-Logs des erlaubten Traffics
• NetFlow- oder IPFIX-Exporte in ein Traffic-Analyse-Tool
• Port-Mirroring auf Switches oder virtuellen Bridges
• Gezielte Packet Captures für besonders auffällige Systeme

Das ist keine glamouröse Arbeit. Sie ist im großen Maßstab aber auch nicht optional.

Sie suchen nach Mustern, die es nie in die Dokumentation geschafft haben. Ein App-Server, der still mit einem File-Server über ein altes Subnetz kommuniziert. Ein Batch-Job, der nur einmal pro Woche läuft. Eine Legacy-Datenbank, von der noch immer alles abhängt, auch wenn es niemand zugibt.

An diesem Punkt hören Migrationen auf, um Virtualisierung zu gehen, und werden zur Archäologie.

Monitoring ist nicht nur für die Zeit nach dem Umzug

Viele Teams verlassen sich bereits stark auf Monitoring-Tools wie Zabbix oder ähnliche Systeme. Was sich während einer Migration ändert, ist, wie viel Vertrauen Sie ihnen entgegenbringen.

Im großen Maßstab wird Monitoring zu Ihrem Sicherheitsnetz. Das Denken verschiebt sich von „ist diese VM gebootet?" zu „sind alle ihre Abhängigkeiten wieder grün?".

Mehrere Admins beschreiben denselben Workflow: eine VM oder eine kleine Gruppe migrieren, warten, bis sich das Monitoring beruhigt hat, dann weitermachen. Wenn etwas kaputtgeht, einen neuen Check hinzufügen. Wiederholen.

Dieser Ansatz verhindert nicht jedes Problem, hält Probleme aber eingedämmt. Sie lernen früh, welche Anwendungen fragil sind und welchen es egal ist, auf welchem Hypervisor sie laufen.

Und ja, das braucht Zeit. Leute, die 300-plus VMs verschoben haben, sprechen in Wochen, nicht in Tagen. Wer eine saubere Wochenend-Umstellung verspricht, hat entweder sehr viel Glück oder liegt sehr falsch.

IPs, VLANs und die Illusion der Gleichheit

Eine der einfachsten Methoden, Risiko zu reduzieren, ist auch eine der langweiligsten: IP-Adressen gleich halten.

Wenn VMs mit derselben IP, demselben VLAN und demselben Gateway hochkommen, verschwindet eine ganze Kategorie von Problemen einfach. DNS muss sich nicht ändern. Firewall-Regeln müssen nicht neu geschrieben werden. Anwendungen finden sich nicht plötzlich dabei wieder, mit dem Falschen zu sprechen.

Aber „die Dinge gleich zu halten" funktioniert nur, wenn Ihr physisches und virtuelles Netzwerk tatsächlich aufeinander abgestimmt sind.

Wenn Ihre Top-of-Rack-Switches nicht die richtigen VLANs getrunkt haben, kann die VM perfekt booten und trotzdem isoliert sein. Wenn sich das Tagging zwischen Umgebungen unterscheidet, kann Traffic lautlos verschwinden. Wenn ARP-Tabellen nicht sauber aktualisieren, bekommen Sie Geister-Konnektivitätsprobleme, die sich zufällig anfühlen, bis Sie sich wieder daran erinnern, dass es sie gibt.

An diesem Punkt legen Migrationen Schwachstellen im Netzwerkdesign offen. Nicht weil Proxmox anders ist, sondern weil Veränderung die Realität an die Oberfläche zwingt.

MAC-Adressen: kleines Detail, große Auswirkung

MAC-Adressen sind eines dieser Details, über die man nicht nachdenkt, bis ein Hersteller Lizenzierung daran koppelt.

Viele Linux-Workloads kommen mit MAC-Änderungen problemlos klar oder lassen sich so konfigurieren, dass die alte Adresse erhalten bleibt. Windows-VMs sind weniger nachsichtig, wenn sich die virtuelle Hardware unter ihnen ändert. Manchmal passen sie sich anstandslos an. Manchmal enumerieren sie Geräte neu und richten Chaos an.

Und dann gibt es noch Oracle. Oder jede andere Software, die MAC- oder UUID-Änderungen als Lizenzereignis behandelt.

Das ist eigentlich kein Proxmox-Problem. Es ist eine Erinnerung daran, dass Virtualisierung Hardware abstrahiert, Lizenz-Hersteller diese Nachricht aber nie erhalten haben.

Warum „migrieren Sie einfach langsam" echter Rat ist

„Eins nach dem anderen migrieren" klingt offensichtlich, bis Sie auf eine Tabelle mit 200 Zeilen starren und ein Unternehmen fragt, wie lange das dauern wird.

Die Leute, die das erfolgreich gemacht haben, sind sich meist in einem Punkt einig: intelligentes Batching schlägt blindes Hetzen.

Sie verschieben eine kleine Gruppe. Sie validieren. Sie reparieren, was kaputtgeht. Sie aktualisieren Dokumentation, die eigentlich schon hätte existieren sollen. Dann verschieben Sie die nächste Gruppe mit weniger Überraschungen.

Das ist nicht schnell. Es ist vorhersehbar.

Und Vorhersehbarkeit ist es, was Migrationen davor bewahrt, zu Feuerwehrübungen für die gesamte Mannschaft zu werden.

Hier geht es eigentlich nicht um Proxmox

Das ist der Teil, der Neulinge überrascht: Nichts davon ist spezifisch für Proxmox.

Sie würden dieselben Geschichten hören, wenn Sie zu KVM, Hyper-V oder einer Public Cloud wechseln. Der Hypervisor-Tausch entfernt lediglich die Sicherheitsdecke der Vertrautheit. Plötzlich werden Annahmen auf die Probe gestellt.

Proxmox ist oft der Überbringer der Nachricht, nicht der Schuldige.

Was es gut macht, ist, Teams zu zwingen, sich damit auseinanderzusetzen, wie ihre Systeme tatsächlich kommunizieren. Das ist unangenehm. Und nützlich.

Die eigentliche Erkenntnis

Wenn Sie eine große ESXi-zu-Proxmox-Migration planen und die meiste Zeit über Compute und Storage nachdenken, unterschätzen Sie wahrscheinlich den schwierigsten Teil.

Die Arbeit steckt im Netzwerk. In den undokumentierten Flows. In den Abhängigkeiten, für die niemand mehr verantwortlich ist. In den Monitoring-Alerts, die Ihnen sagen, dass etwas nicht stimmt, aber nicht warum.

Behandeln Sie das wie ein Netzwerkprojekt mit einer Virtualisierungskomponente, nicht umgekehrt.

Tun Sie das, und der Import-Assistent wird wirklich der einfache Teil sein.