50.000 VMs und ein bitterer Abschied: das Chaos hinter einem ungewollten VMware-Exit
Die Migration, um die niemand gebeten hat
Es gibt eine besondere Art von Frustration, wenn eine technische Entscheidung von etwas getrieben wird, das über der Technik liegt: Lizenzänderungen, Konzernumbrüche oder das, was eine Stimme unverblümt „das Schlimmste, was je passiert ist" nannte. Aus dieser Stimmung heraus entsteht eine gewaltige Migration, bei der rund 1.000 Hosts und 50.000 virtuelle Maschinen von VMware auf Hyper-V gedrängt werden. Dabei hat der Stack weder versagt noch Probleme mit der Skalierung gehabt. Verschoben hat sich der Boden darunter.
Daraus entsteht die Spannung. Ein Techniker gibt zu, ein „großer Fan" von VMware zu sein, und hat gleichzeitig den Auftrag, es abzubauen. Neben der technischen Arbeit ist das auch emotionale Arbeit. Er muss etwas neu aufbauen, dem er vertraut hat, und das in einer Größenordnung, in der Fehler lange nachhallen.
Tools, Skripte und die Illusion von „einfach"
Fragt man in die Runde, kommen die ersten Antworten schnell und selbstbewusst. „Der StarWind V2V Converter ist Ihr bester Freund", sagt jemand. Ein anderer schwört auf backup-basierte Migration mit Veeam und nennt sie „extrem einfach", wenn das Ökosystem bereits vorhanden ist. Auf dem Papier klingt das fast schon sauber: konvertieren, wiederherstellen, booten, fertig.
Doch dann zeigen sich die Risse. Jemand anders weist darauf hin, dass der Prozess nicht mehr so sauber verläuft, sobald man über ein paar Dutzend Maschinen hinausskaliert. Das Entfernen von VMware Tools wird zu einer eigenen kleinen Schlacht, Treiber verhalten sich nicht immer wie erwartet, und versteckte Netzwerkadapter kollidieren mit den IP-Einstellungen. „Man muss das Gateway zweimal setzen", lässt jemand beiläufig fallen, als gehöre das einfach zum Ritual.
Tools versprechen Einfachheit, aber mit der Größe wächst die Reibung. Was bei 25 VMs funktioniert, gerät bei 200 ins Wanken und bricht bei 50.000 komplett ein.
Skalierung verändert alles
Ein Kommentator hält kurz inne, nur um die schiere Größe anzuerkennen: „50.000 VMs … ein ziemlich interessantes Migrationsprojekt. Viel Glück." Das liest sich weniger wie Ermutigung und mehr wie ein Nicken in Richtung des Sturms, der noch bevorsteht.
Eine andere Stimme bringt praktische Erfahrung ein: die Migration von über 200 VMs über mehrere Standorte hinweg in gut einem Monat, und zwar nicht freiwillig. Dieses Detail zählt, denn erzwungene Zeitpläne lassen keine perfekte Planung zu. Sie erzwingen Kompromisse wie parallele Migrationen, provisorische Fixes und Skripte, die „größtenteils funktionieren". Und das Projekt hier ist 250-mal so groß.
In dieser Größenordnung werden aus ordentlichen Checklisten Überlebenstaktiken. Automatisierung ist Pflicht, und Cleanup-Skripte entscheiden darüber, ob der Rollout kontrolliert abläuft oder nach der Migration wochenlang Feuer gelöscht wird.
Drei Lager, drei Realitäten
Auffällig ist, wie gespalten die Perspektiven sind, weniger im Inhalt als im Tonfall.
Eine Gruppe ist pragmatisch und konzentriert sich auf Tools, Workflows und Effizienz. „Nutzen Sie diesen Converter." „Führen Sie dieses PowerShell-Skript aus." „So schlimm ist es nicht, wenn man sich vorbereitet." Das sind die Macher, die schon genug Migrationen hinter sich haben, um zu wissen, wo die Minen liegen.
Eine andere Gruppe ist vorsichtig, fast skeptisch. Sie spricht die unschönen Seiten an, also Treiberprobleme, VMware-Reste und Netzwerk-Eigenheiten. Ihr Rat liest sich wie eine Warnung: Unterschätzen Sie die Cleanup-Phase nicht. Die Migration ist erst abgeschlossen, wenn die VM sich richtig verhält, und nicht schon, wenn sie bootet.
Die leisere dritte Gruppe bietet weder Tools noch Schritte an und reagiert einfach auf Größenordnung und Kontext. „Viel Glück." „Das ist ein riesiges Projekt." Auch das hilft, weil es ehrlich ist. Manchmal ist die einzig zutreffende Reaktion auf ein so großes Projekt, anzuerkennen, wie schwer es wirklich ist.
Die versteckten Kosten des Abschieds
Unausgesprochen schwingt noch etwas mit: Der Abschied von einer Plattform, der man vertraut, kostet mehr als Lizenzgebühren.
Sie verlieren eingespielte Routinen und Jahre an Feintuning, Abkürzungen und Instinkten. Plötzlich muss Ihr Team die Grundlagen in einem anderen Ökosystem neu lernen. Selbst wenn Hyper-V leistungsfähig ist, und viele argumentieren, dass es das ist, gibt es diesen Übergang nicht umsonst.
Jemand erwähnt bessere Ergebnisse mit den Migrationstools des Windows Admin Center, allerdings mit einem Haken: Man braucht weiterhin vCenter im Spiel. Dieses Detail sagt viel aus. Selbst beim Abschied von VMware stützt man sich während der Übergangsphase noch darauf, als würde man aus einem Haus ausziehen und die alten Schlüssel brauchen, um die Koffer zu packen.
Dazu kommen die Kosten im wörtlichen Sinn. Tools wie Zerto werden als „sehr gut, aber wahnsinnig teuer" erwähnt. Der Entscheidungsbaum wird also schnell kompliziert: auf einer Plattform sparen, auf einer anderen ausgeben und dabei Risiko, Zeit und Budget gegeneinander abwägen.
Keine sauberen Enden, nur Kompromisse
Heraus kommt eine Sammlung von Kompromissen, aus der sich kein klarer „bester Weg" zu migrieren ablesen lässt.
Backup-basierte Migration ist flexibel, kann aber Eigenheiten mit sich bringen. Konvertierungstools sind schnell, brauchen aber Nacharbeit. Native Tools integrieren sich gut, hängen aber oft von bestehender Infrastruktur ab. Jeder Weg löst ein Problem und schafft gleichzeitig ein neues.
Vielleicht handelt die Geschichte dahinter vor allem davon, dass groß angelegte Infrastrukturentscheidungen selten sauber sind. Sie werden von externem Druck geformt, unter Einschränkungen umgesetzt und von Technikern zusammengehalten, die sich unterwegs alles selbst erarbeiten.
Ein Satz bleibt hängen: „Kein schlechter Prozess … wenn man nicht Tausende hat." Im Kleinen fühlt sich alles beherrschbar an, im Enterprise-Maßstab wird alles zu einem System aus Grenzfällen.
Einige der schwierigsten Probleme in der Technik sind gar nicht technischer Natur: Die Entscheidung ist längst gefallen, und Sie sind derjenige, der sie zum Laufen bringen muss.