1.500 VMs, ein falscher Schritt: Die brutale Realität der VMware-Flucht, ohne alles kaputtzumachen
"1.500 VMs, ein falscher Schritt: Die brutale Realität der VMware-Flucht, 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 ist das kein Projekt mehr – es ist ein Glücksspiel mit echten Konsequenzen. Der Plan klingt auf dem Papier sauber: alles von VMware vSAN wegziehen und sicher bei Proxmox landen. Aber fast sofort zeigen sich die ersten Risse.
Das erste Problem taucht schnell auf: 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." Das erzwingt eine unbequeme Realität. Sie migrieren nicht direkt. Sie staffeln, springen und jonglieren mit Storage-Schichten, nur um die Daten herauszubekommen. Und 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 – bis sie es nicht mehr ist
In einem Punkt sind sich alle einig: Manuell ist das nicht zu schaffen. Nicht mal ansatzweise. Hier kommt der CI/CD-Traum ins Spiel – GitLab-Runner, Ansible-Playbooks, Terraform-Provisioning. Das klingt alles nach einer sauberen Pipeline: exportieren, konvertieren, importieren, fertig.
Und technisch funktioniert es auch. Eine Stimme legte es selbstbewusst dar: "Terraform für die Infrastruktur-Provisionierung und Ansible obendrauf für die Migration." Das ist das Idealbild.
Doch die Realität schleicht sich ein. Automatisierung beseitigt Komplexität nicht – sie verstärkt sie. Jetzt skaliert jeder Fehler über Hunderte von Maschinen hinweg. Ein schlechtes Playbook, eine falsche Annahme über Treiber oder Netzwerk, und plötzlich reparieren Sie nicht mehr eine VM – Sie löschen Brände auf Dutzenden oder Hunderten gleichzeitig.
In der Diskussion steckt auch ein leises Eingeständnis: Groß angelegte Automatisierung wurde schon zuvor durchgeführt, sogar bei 8.000 Servern. Das macht es aber nicht einfach. Es beweist nur, dass man es überleben kann.
Das Windows-Problem, das niemand haben will
Wenn Linux der einfache Teil dieser Geschichte ist, wird es bei Windows schnell unübersichtlich. Nicht konzeptionell – nur praktisch. Treiber, Boot-Probleme, Bluescreens, die nur auf ihren Auftritt warten.
Manche Ingenieure haben Workflows entwickelt, die inzwischen fast rituell wirken. VirtIO-Treiber vor der Migration installieren. VMware Tools erst im allerletzten Moment entfernen. Einmal mit SATA booten, nur um den Treiber "aufzuwecken", dann 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.
Hier verändert sich der Ton. Es geht nicht mehr um Architektur – es geht um Überlebenstaktik. Jeder hat eine leicht andere Methode, und keine davon fühlt sich kugelsicher an. Sie fühlen sich nur ausreichend erprobt an, um ihnen zu vertrauen.
Geschwindigkeit vs. Ausfallzeit: Entscheiden Sie sich
Eine der härtesten Wahrheiten in diesem gesamten Prozess: Sie bekommen nicht alles. Geschwindigkeit, geringe Ausfallzeit, Einfachheit – auf mindestens eines davon müssen Sie 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. Aber es gibt hier auch Frust, besonders wegen des Fehlens 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 Methoden kosten Sie Betriebszeit.
Und wenn Sie es mit Hunderten oder Tausenden von Systemen zu tun haben, ist Ausfallzeit nicht nur technisch – sie ist politisch. Irgendjemand wartet immer darauf, dass diese Systeme wieder online gehen.
Die verborgene Ebene: Storage ist der eigentliche Engpass
Was sich aus alledem still herauskristallisiert: Storage – nicht Compute, nicht Automatisierung – ist die eigentliche Einschränkung. vSAN spielt bei direkten Migrationspfaden nicht mit. Das erzwingt Workarounds: zwischengeschaltete NFS-Shares, temporäre Storage-Systeme, sogar das Aufsetzen von etwas wie TrueNAS, nur um Daten hin- und herzubewegen.
In dieser Größenordnung wird das Verschieben von Daten zum dominierenden Problem. Nicht das Konfigurieren von VMs. Nicht das Skripten von Workflows. Einfach nur Bits von einem Ort zum anderen zu bewegen, ohne sie zu beschädigen.
Und genau da geraten viele Pläne ins Stocken. Nicht, weil sie schlecht konzipiert sind, sondern weil die zugrunde liegenden Systeme von Anfang an nicht dafür gebaut wurden, 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 nur ein großes, aber beherrschbares Projekt.
Zweitens die Pragmatiker. Sie haben schon Migrationen durchgeführt. Sie wissen, dass es chaotisch ist, voller Sonderfälle steckt und nur durch Skripte und Workarounds zusammengehalten wird. Ihr Fokus liegt auf dem, was funktioniert, nicht auf dem, 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.
Keiner von ihnen liegt falsch.
Denn die Wahrheit ist: Eine Migration dieser Art ist nicht nur technisch. Sie ist strategisch. Sie verschieben nicht einfach nur VMs – Sie verändern das Fundament, auf dem alles läuft. Und sobald Sie einmal angefangen haben, gibt es keinen sauberen Weg, auf halber Strecke innezuhalten.
Das ist der Teil, den niemand laut ausspricht. Aber Sie spüren ihn in jedem Kommentar.