„Wir gehen endlich … aber zu welchem Preis?“ Was die Trennung von VMware in der Praxis bedeutet

Die erste Woche fühlt sich an wie kontrolliertes Chaos

Woche eins einer Migration hat etwas seltsam Ehrliches. Es gibt noch keine polierte Fallstudie und keine vom Hersteller abgesegnete Erfolgsgeschichte, nur eine laufende Liste dessen, was funktioniert hat, was kaputtgegangen ist und wovor einen niemand gewarnt hat. Ein Ingenieur legte es schlicht dar: Sie ziehen von VMware zu HPEs Morpheus und VM Essentials um, und es bewegt sich „in die richtige Richtung".

Dieser Optimismus zählt, wird aber durch Reibung gedämpft. Die Netzwerkvorbereitung half, doch eine übersehene MTU-Einstellung auf den iSCSI-Ports verlangsamte alles. Solche Fehler stehen in keiner Präsentation, tauchen aber garantiert um 2 Uhr morgens beim Deployment auf. Zu einer Migration gehört eben neben der Strategie auch ein Haufen winziger Details, die nur darauf warten, einen stolpern zu lassen.

Die Illusion „einfacherer" Alternativen

Auf dem Papier sieht ein Plattformwechsel oft wie eine Vereinfachung aus, in der Praxis tauscht man eher eine Art von Komplexität gegen eine andere. Der Wechsel zu KVM auf Hypervisor-Ebene brachte eine subtile Verschiebung mit weniger Abstraktion und mehr direkter Interaktion. „Es ist immer noch etwas Linux und Kommandozeile dabei", stellte der Ingenieur fast beiläufig fest.

Manche empfinden das als Befreiung, andere als Rückschritt. Eine Stimme im Netz zuckte mit den Schultern: „Für nicht kritische Systeme reicht alles", was nahelegt, dass vielleicht nicht jede Workload Enterprise-Politur braucht.

Darin liegt die Spannung. VMware hat seinen Ruf darauf aufgebaut, Komplexität zu verstecken, und wer geht, fängt an, sie wieder zu sehen. Ob das ein Feature oder ein Fehler ist, hängt davon ab, wer hinschaut.

Die Kompatibilitäts-Minenfelder, über die kaum jemand spricht

Die echten Überraschungen kommen von den Rändern, weniger von der Kernplattform. TPM-Support etwa entwickelte sich zu einer unerwarteten Komplikation: VMware bietet vTPM, die neue Umgebung nicht wirklich, zumindest nicht auf dieselbe Art.

„Das ist kein Show-Stopper", sagte der Ingenieur. Trotzdem erinnert es daran, dass jede VM ihre eigene Geschichte hat und sich nicht alle sauber übersetzen lassen.

Andere widersprachen härter. Ein Kommentar warnte, TPM in einer Windows-lastigen Umgebung zu ignorieren, sei riskant und obendrein kurzsichtig. „Es wird nicht mehr lange dauern, bis es erforderlich ist."

Eine dritte, pragmatischere Perspektive lautet: priorisieren, was zählt, also erst kritische Systeme testen und sich später um den Rest kümmern. Perfekt ist das nicht, aber Migrationen sind das selten.

Verschlüsselung: Philosophie trifft auf Praxis

Wenn TPM eine technische Hürde ist, dann ist Verschlüsselung eine philosophische. VMware handhabt Verschlüsselung auf VM-Ebene, der neue Stack setzt stattdessen auf Verschlüsselung auf Storage-Ebene. Das klingt vernünftig, bis man an eine Wand stößt: Man kann verschlüsselte VMs nicht direkt migrieren.

Plötzlich wird aus einer Designentscheidung ein Migrationsblocker. Manche Ingenieure stimmen dem Storage-first-Ansatz zu, denn warum sollte man zweimal verschlüsseln? Andere sehen darin eine Einschränkung, besonders in Umgebungen mit strengen Sicherheitsrichtlinien.

Dazu kommt der praktische Blickwinkel. Ein Kommentator wies darauf hin, dass Verschlüsselung auf VM-Ebene die Performance tatsächlich beeinträchtigen kann, weil sie Deduplizierung und Kompression bricht. Ein anderer konterte mit Beispielen fortgeschrittener VMware-Storage-Integrationen, die den I/O-Overhead drastisch reduzieren. Aus demselben Problem wurden so drei verschiedene Schlussfolgerungen, was bei Infrastruktur-Debatten ziemlich normal ist.

Der „Haben Sie das überhaupt getestet?"-Moment

Keine Migrationsgeschichte kommt ohne nachträgliches Infragestellen aus, und hier kam es schnell. „Haben Sie keinen PoC gemacht?", fragte ein Kommentator unverblümt.

Die Frage ist fair und ein wenig gemein. Proof-of-Concept-Tests sollen eigentlich Probleme wie fehlenden TPM-Support oder Verschlüsselungseinschränkungen auffangen, aber in der Praxis schafft es nicht alles auf die Prioritätenliste. Der Ingenieur gab das zu: Manche Systeme wurden zurückgestellt, manche waren veraltet, und andere schienen zum jeweiligen Zeitpunkt einfach nicht kritisch.

Migrationen stecken nun einmal voller Kompromisse. Man kann nicht alles gleich gründlich testen, und manchmal entdeckt man die Lücken erst, wenn man schon mittendrin ist.

Nicht jeder hält das für rational

Während manche einen durchdachten Übergang sehen, sehen andere vor allem Emotion. „Das sind emotionale Entscheidungen", argumentierte ein Kommentator und deutete an, dass der Schritt eher Reaktion als Strategie sein könnte.

Die Einschätzung ist hart, spiegelt aber eine breitere Spaltung wider. Für manche Teams fühlt sich der Abschied von VMware überfällig an, als Reaktion auf Preisgestaltung, Lizenzänderungen oder verschobene Prioritäten. Für andere sieht es aus, als gäbe man ein ausgereiftes Ökosystem zugunsten von etwas weniger Erprobtem auf.

Dazwischen stehen Leute, die von keiner Richtung völlig überzeugt sind, aber genau hinschauen, sich Notizen machen und abwarten, wie diese frühen Migrationen verlaufen.

Der langsame Schwung des Weggehens

Am meisten fällt der Ton auf. Der Ausstieg läuft gemessen, vorsichtig und in kleinen Schritten ab. „Wir posten mehr, während wir voranschreiten", schrieb der Ingenieur.

So laufen diese Verschiebungen tatsächlich ab: ohne große Ankündigung, mit schrittweisen Updates, geteilten Lektionen und dem wachsenden Gefühl, dass Bleiben schwerer sein könnte als Gehen.

Andere meldeten sich mit eigenen Erfahrungen zu Wort, auf unterschiedlichen Plattformen, aber mit ähnlichen Herausforderungen und fast denselben Ratschlägen: Abhängigkeiten früh abbilden, Backups testen und auf Netzwerk-Fallstricke achten.

Für viele Teams ist der Ausstieg aus VMware ein Prozess, der gerade erst begonnen hat.