1.500 VMs, ein falscher Schritt: Wie man VMware verlässt, ohne alles kaputtzumachen

Wenn "Migration" aufhört, ein Buzzword zu sein, und sich wie ein Risiko anfühlt

Es ist ein großer Unterschied, ob Sie eine Handvoll VMs migrieren oder einer Zahl wie 1.500 gegenüberstehen. In dieser Größenordnung wird aus dem Projekt ein Glücksspiel mit echten Konsequenzen. Der Plan klingt auf dem Papier sauber: alles von VMware vSAN wegziehen und sicher bei Proxmox landen. Fast sofort zeigen sich aber die ersten Risse.

Das erste Problem taucht schnell auf, denn es gibt keine saubere Brücke aus vSAN heraus. Ein Ingenieur brachte es unverblümt auf den Punkt: "Option 1 wird nicht funktionieren … der Migrationsjob wird fehlschlagen." Sie migrieren also nicht direkt, sondern staffeln, springen und jonglieren mit Storage-Schichten, nur um die Daten herauszubekommen. Jeder zusätzliche Schritt kostet Zeit, erhöht das Risiko und die Möglichkeit, dass mitten im Flug etwas kaputtgeht.

Automatisierung klingt nach der Antwort, hat aber Grenzen

In einem Punkt sind sich alle einig: Manuell ist das nicht einmal ansatzweise zu schaffen. Deshalb kommt der CI/CD-Traum ins Spiel, mit GitLab-Runnern, Ansible-Playbooks und Terraform-Provisioning. Das klingt nach einer sauberen Pipeline: exportieren, konvertieren, importieren, fertig.

Technisch funktioniert das auch. Eine Stimme legte es selbstbewusst dar: "Terraform für die Infrastruktur-Provisionierung und Ansible obendrauf für die Migration." So sieht das Idealbild aus.

In der Praxis verstärkt Automatisierung die Komplexität eher, als sie zu beseitigen, weil jeder Fehler jetzt über Hunderte von Maschinen skaliert. Ein schlechtes Playbook oder eine falsche Annahme über Treiber oder Netzwerk, und plötzlich reparieren Sie nicht mehr eine VM, sondern löschen Brände auf Dutzenden oder Hunderten gleichzeitig.

Die Diskussion räumt auch ein, dass groß angelegte Automatisierung schon zuvor durchgeführt wurde, sogar bei 8.000 Servern. Einfach wird es dadurch nicht, aber es zeigt, dass man es überleben kann.

Das Windows-Problem, das niemand haben will

Linux ist der einfache Teil dieser Geschichte. Bei Windows wird es schnell unübersichtlich, weniger konzeptionell als praktisch: Treiber, Boot-Probleme und Bluescreens, die nur auf ihren Auftritt warten.

Manche Ingenieure haben Workflows entwickelt, die inzwischen fast rituell wirken. Sie installieren die VirtIO-Treiber vor der Migration, entfernen die VMware Tools erst im allerletzten Moment und booten einmal mit SATA, nur um den Treiber "aufzuwecken", bevor sie zu VirtIO wechseln. Elegant ist das nicht, aber es funktioniert.

"Ich boote einmal mit der Systemplatte als SATA … dann wechsle ich", erklärte eine Person. Eine andere ging noch weiter und nutzte Tools wie devcon, um Treiber einzuschleusen, bevor die Hardware überhaupt existiert.

An dieser Stelle verschiebt sich der Ton von Architektur zu Überlebenstaktik. Jeder hat eine leicht andere Methode, und keine davon fühlt sich kugelsicher an, nur ausreichend erprobt, um ihr zu vertrauen.

Geschwindigkeit vs. Ausfallzeit: Entscheiden Sie sich

Sie bekommen in diesem Prozess nicht alles. Zwischen Geschwindigkeit, geringer Ausfallzeit und Einfachheit müssen Sie auf mindestens eines verzichten.

Manche setzen auf Backup-Tools wie Veeam, weil "der normale Import zu langsam ist". Andere nehmen die Ausfallzeit in Kauf, weil sie besser planbar ist. Es gibt allerdings auch Frust, besonders über das Fehlen einer echten Replikation nach Proxmox.

"Wir haben Backup und Restore gemacht … aber die Ausfallzeit ist höher, als uns lieb ist." Das ist der Kompromiss in einfachen Worten: Schnellere Methoden bedeuten oft mehr Risiko, sicherere kosten Betriebszeit.

Bei Hunderten oder Tausenden von Systemen ist Ausfallzeit außerdem auch ein politisches Thema, denn irgendjemand wartet immer darauf, dass diese Systeme wieder online gehen.

Die verborgene Ebene: Storage ist der eigentliche Engpass

Aus alledem ergibt sich, dass Storage die eigentliche Einschränkung ist, mehr als Compute oder Automatisierung. vSAN spielt bei direkten Migrationspfaden nicht mit. Das erzwingt Workarounds wie zwischengeschaltete NFS-Shares, temporäre Storage-Systeme oder sogar das Aufsetzen von etwas wie TrueNAS, nur um Daten hin- und herzubewegen.

In dieser Größenordnung dominiert das Verschieben der Daten alles andere. Das Konfigurieren von VMs und das Skripten von Workflows treten dahinter zurück; schwierig ist es, Bits von einem Ort zum anderen zu bewegen, ohne sie zu beschädigen.

Genau da geraten viele Pläne ins Stocken. Das liegt nicht an schlechter Konzeption: Die zugrunde liegenden Systeme wurden von Anfang an nicht dafür gebaut, zusammenzuarbeiten.

Drei Denkweisen, eine gewaltige Entscheidung

Betrachtet man alle Perspektiven, kristallisieren sich drei unterschiedliche Denkweisen heraus.

Erstens die Optimisten. Sie glauben an Automatisierung, Pipelines und saubere Architektur. Mit den richtigen Tools ist das für sie nur ein großes, aber beherrschbares Projekt.

Zweitens die Pragmatiker. Sie haben schon Migrationen durchgeführt und wissen, dass es chaotisch ist, voller Sonderfälle steckt und nur durch Skripte und Workarounds zusammengehalten wird. Sie achten darauf, was funktioniert, und weniger darauf, was elegant ist.

Und drittens die Vorsichtigen. Sie sorgen sich um Ausfallzeit, Datenintegrität und das schiere Schadensausmaß von Fehlern. Für sie ist jeder Schritt eine Risikokalkulation.

Keine dieser Gruppen liegt falsch, denn eine Migration dieser Art ist technisch und strategisch zugleich. Sie verschieben VMs und verändern dabei das Fundament, auf dem alles läuft. Sobald Sie einmal angefangen haben, gibt es keinen sauberen Weg, auf halber Strecke innezuhalten. Laut ausgesprochen wird das selten, aber man spürt es in jedem Kommentar.