VMware-Ausstieg: Backups, Downtime und Altlasten
Die Argumentation für einen Abschied von VMware beginnt meist mit einer Tabelle. Das ist verständlich, denn die Rechnung trifft als erstes ein. Nach den Lizenzänderungen durch Broadcom stellten viele IT-Teams dieselbe Rechnung auf: Was zahlen wir heute, was haben wir früher bezahlt und welcher Aufwand entsteht bei einem Plattformwechsel? Für etliche Betriebe scheint das Ergebnis eindeutig genug, um die Suche nach Alternativen ernsthaft voranzutreiben.
Die Kalkulation ist jedoch der einfache Teil. Deutlich anspruchsvoller ist all das, was in keinen einfachen Preisvergleich passt: die Backup-Kette, die jahrelang geräuschlos ihren Dienst verrichtet hat, die virtuelle Appliance eines Drittherstellers, die eigentlich nur in einer VMware-Umgebung zuverlässig arbeitet, und das Wartungsfenster, das zwar auf dem Papier existiert, im Geschäftsalltag aber kaum durchsetzbar ist. Hinzu kommt das in die Jahre gekommene Monitoring, auf das sich dennoch alle verlassen, sowie die unbemerkte Abhängigkeit zwischen einem „provisorischen“ System aus dem Jahr 2017 und einer Kernanwendung, an der heute der halbe Geschäftsbetrieb hängt. An dieser Stelle wird der Ausstieg aus VMware zur Geduldsprobe.
In einer Online-Diskussion unter Infrastruktur-Experten stellte ein Unternehmen aus Indien eine einfache Frage: Vor welcher Hürde standen Teams, die VMware bereits verlassen haben, in der Praxis wirklich? Sie suchten nach ehrlichen Antworten jenseits von Marketing-Präsentationen und bunten Folien. Genannt wurden die üblichen Verdächtigen: Komplexität der Migration, Ausfallrisiken, Einarbeitung des Teams, Qualität des Herstellersupports, Kompatibilität, Performance und laufender Betriebsaufwand. Die Antworten liefen schnell auf einen gemeinsamen Nenner hinaus: Zu bemerken, wie viele Aufgaben VMware jahrelang unbemerkt im Hintergrund abgefedert hat, ist oft unangenehmer als das reine Konvertieren der virtuellen Maschinen.
Einer der treffendsten Kommentare fasste es nüchtern zusammen: Die eigentlichen Hürden liegen abseits der VM-Konvertierung, nämlich bei Backup-Transportmechanismen, Snapshots, Hersteller-Appliances, Monitoring und Wartungsfenstern, kurz bei all jenen Dingen, die VMware so reibungslos abwickelte, dass man sie gar nicht mehr wahrnahm. Der Rat war unmissverständlich: Führen Sie einen Pilotversuch für Abhängigkeiten und Disaster Recovery durch, bevor Sie sich für das Logo einer neuen Plattform begeistern. Dieser Satz gehört an den Anfang jedes Migrationskonzepts.
Jede Demo einer neuen Plattform wirkt überzeugend: Einige VMs werden verschoben, das Dashboard meldet Vollzug und eine Workload läuft sichtbar stabil unter Proxmox, Hyper-V, OpenShift Virtualization, XenServer, Nutanix oder einer anderen Alternative auf der Auswahlliste. Die Anspannung im Raum weicht spürbar. Vielleicht wird der Wechsel doch nicht so schwer.
Dann fällt die Frage nach den Backups, und zwar nicht im unverbindlichen Sinne von „Können wir das überhaupt sichern?“. Die entscheidende Frage lautet vielmehr: Können wir die Systeme genauso sichern wie bisher, mit denselben Vorgaben für RPO und RTO, derselben Anwendungskonsistenz, demselben Verhalten bei Snapshots, derselben Transporteffizienz und derselben Sicherheit nachts um 2:17 Uhr, wenn eine erfolgreiche Wiederherstellung das Einzige ist, was zwischen einem Ausfall und einem massiven Problem steht? An diesem Punkt gerät die scheinbar einfache Migrationsgeschichte ins Wanken.
Der Vorsprung von VMware lag nie allein im Hypervisor, sondern im umgebenden Ökosystem. Anbieter von Backup-Lösungen, Storage-Systemen, Monitoring-Werkzeugen, Sicherheitssoftware und Spezial-Appliances kennen diesen Umstand genau. Über Jahre hinweg wuchsen Schnittstellen und Integrationen rund um vSphere und vCenter, bis VMware weniger wie ein einzelnes Softwareprodukt wirkte, sondern wie der eigentliche Hallenboden des Rechenzentrums. Einen Boden kann man austauschen. Man möchte nur nicht mitten im Umbau feststellen, dass darunter die gesamten Versorgungsleitungen einbetoniert sind.
Datensicherungen wurden in der Diskussion immer wieder genannt, teils in ausführlichen Absätzen, teils als Warnung in einem einzigen Wort: „Backups!“ Dieser einzelne Ausruf hat Gewicht. Fachleute für Infrastruktur werden bei Backups nicht aus Freude am Drama emotional, sondern weil dort Theorie auf echte Betriebsrisiken trifft.
Ein Backup-Job, der technisch ohne Fehler durchläuft, ist noch kein funktionierender Wiederherstellungsplan. Ebenso bedeutet eine wiederhergestellte VM, die startet, noch längst keinen funktionsfähigen Dienst. Snapshot-basierte Sicherungen, die auf einer Plattform Routine waren, können auf einer anderen erhebliche Probleme bereiten, insbesondere wenn Speicher anders angesprochen wird, geteilter Storage Einschränkungen mitbringt oder sich das neue Setup nicht deckungsgleich auf das alte übertragen lässt. Ein Administrator, der Kunden zu Proxmox migriert, berichtete von insgesamt sehr guten Erfahrungen, nannte als größte Hürde jedoch die veränderte Funktionsweise von Speicher und Snapshots. Das ist keine Randnotiz, denn damit verändert sich das Betriebsmodell für das gesamte Team.
Ein weiterer Teilnehmer verwies auf Supportfragen bei Drittanbietern und den Lebenszyklus von Block-Storage als wesentliche Hürden. Proxmox mit Shared Storage über iSCSI funktioniere zwar, zwinge Teams aber zum Umdenken, wobei Snapshot-Backups zu einer echten Herausforderung werden können. Details dieser Art finden sich selten in Management-Zusammenfassungen zur Migration, gehören dort aber zwingend hinein.
Hinzu kommen die zahllosen Appliances, die in jeder gewachsenen VMware-Umgebung existieren. Manche stammen offiziell von Herstellern, andere wurden vor Jahren von Kollegen aufgesetzt, die das Unternehmen längst verlassen haben. Darunter finden sich Linux-Appliances, die so unauffällig arbeiteten, dass niemand mehr das Root-Passwort kennt, geschweige denn die genauen Treiberanforderungen. Gewöhnliche Server-Workloads zu verschieben ist die eine Sache, virtuelle Appliances zu migrieren eine ungleich schwerere.
Ein Team, das auf OpenShift Virtualization umstellte, bezeichnete Appliances als größte Hürde. Manche Hersteller bieten KVM-Images an, einige Systeme lassen sich konvertieren, andere wiederum bringen schlicht nicht die notwendigen Treiber mit, um sauber unter KVM zu starten. Das ist ein rein praktisches Problem ohne jede weltanschauliche Dimension über Open Source versus kommerzielle Software: Es ist schlicht ein System, das vorher startete und es nun vielleicht nicht mehr tut.
Besonders heikel wird es, wenn eine Lösung von einem Hersteller stammt, der ausschließlich VMware zertifiziert. Dann können das Migrationsteam, das Unternehmen und die neue Zielplattform bereit sein, während die Support-Matrix des Herstellers den Weg versperrt. Aus der Auswahl einer alternativen Plattform wird dann plötzlich eine zeitraubende Verhandlung mit jedem einzelnen Softwarelieferanten im Unternehmen.
Ausfallzeiten sind eine weitere typische Stolperfalle. Jeder wünscht sich einen unterbrechungsfreien Betrieb, doch für notwendige Wartungsfenster wird fast immer zu wenig Zeit eingeplant.
VMware hat die Erwartungshaltung über Jahre geprägt. vMotion ließ Wartungsarbeiten im besten Sinne unspektakulär wirken. Hosts konnten evakuiert, Workloads verschoben und Patches eingespielt werden, ohne dass daraus ein Drahtseilakt wurde. Ein VMware-Mitarbeiter gab in der Diskussion zu bedenken, dass Virtualisierungslösungen auf Kubernetes-Basis und andere modernere Plattformen bei Backup-APIs und der Reife für Wartungsfenster noch Nachholbedarf gegenüber VMware haben. Er nannte Live-Patching von ESXi und Verbesserungen an vMotion als Beispiele für funktionale Reife im Betrieb, die sich nicht über Nacht nachbauen lässt.
Man muss diese Argumentation nicht in jedem Punkt teilen, um den Kern der Aussage zu verstehen: VMware hatte Jahrzehnte Zeit, die Kanten des täglichen Betriebs abzuschleifen. Alternativen können leistungsfähig sein und für manche Unternehmen die bessere Wahl darstellen, doch ein Plattformwechsel bedeutet immer, neu zu lernen, wo die scharfen Kanten liegen.
Wartungsfenster wirken simpel, bis Systeme bewegt werden müssen, die rund um die Uhr verfügbar sein müssen. Ein Experte, der gerade eine Kundenmigration abgeschlossen hatte und eine Testumgebung auf Hyper-V umstellte, berichtete, dass die eigentliche Verschiebung mit Tools wie Veeam oder StarWind reibungslos lief. Der Engpass lag vielmehr bei kritischen Fachanwendungen und knappen Zeitfenstern. Er riet dazu, frühzeitig zu beginnen, vor allem wenn auslaufende Subskriptionsverträge eine harte Frist setzen. Ein Ausfall im Labor ist ärgerlich, eine unvorhergesehene Downtime im Produktivbetrieb über Hunderte Systeme und Benutzer hinweg ist dagegen ein ernster Vorfall.
Das Management unterschätzt bisweilen, dass Migrationsrisiken ungleich verteilt sind. Zehn unkomplizierte VMs lassen einen Zeitplan schnell gesund wirken, während eine einzige widerborstige Appliance einer Kernanwendung das gesamte Projekt ins Stocken bringen kann.
Hinzu kommen gewachsene Altlasten. VMware-Migrationen entwickeln sich regelmäßig zur technischen Archäologie. Man beginnt mit dem Verschieben von Workloads und stößt bald auf veraltete Authentifizierungsmechanismen, Annahmen beim Speicher, Sonderlocken beim Backup und Systeme, die niemand anfasste, weil jede Änderung als riskant galt. Ein Diskussionsbeitrag brachte es auf den Punkt: Das ist der Moment, in dem man die Leichen im Keller beseitigen muss, die man jahrelang ignoriert hat. Das ist mühsam, bietet aber auch die Chance zum Aufräumen.
Ein Abschied von VMware ist oft ein Sanierungsprojekt im Gewand einer Kostensenkungsmaßnahme. Daran ist nichts verkehrt, solange man ehrlich damit umgeht. Wenn die Umgebung voller undokumentierter Abhängigkeiten steckt und die Migration hakt, liegt das an den Altlasten. VMware verstand es über lange Zeit lediglich meisterhaft, diese Probleme zu kaschieren.
Verzichten Sie daher im ersten Schritt auf den großen Plattformvergleich und beginnen Sie mit einem echten Wiederherstellungstest. Starten Sie mit der problematischsten Anwendung, der Appliance, die niemand anfassen will, der Workload mit der geringsten Toleranz für Ausfälle und dem Hersteller, dessen Supportportal immer noch ausschließlich VMware auflistet. Die Auswahl des neuen Logos kann warten.
Den Erfolg entscheidet, ob das Team die neue Umgebung zuverlässig wiederherstellen, patchen, überwachen, sichern, unterstützen und betreiben kann, ohne jede Woche einen neuen Notfall auszurufen. Eine günstigere Plattform mit mehr manuellem Aufwand kann sinnvoll sein. Eine offenere Lösung mit steilerer Lernkurve kann langfristig die richtige Entscheidung sein. Selbst eine Verlängerung bei VMware kann für manche große oder eng verzahnte Umgebungen die pragmatische Wahl bleiben. Es gibt keine einfache Standardantwort, was den sachlichen Ton der Diskussion erklärt.
Der Ausstieg aus VMware ist machbar, und viele Unternehmen setzen ihn derzeit um. Einige wirken erleichtert, manche erschöpft, und andere stehen mitten im Übergang und stellen erst jetzt fest, was alles fest mit der alten Basis verschraubt war.
Die zentrale Lehre lautet: Verwechseln Sie die Konvertierung einer VM nicht mit einer vollständigen Plattformmigration. Die VM ist nur der sichtbare Teil an der Oberfläche. Dahinter stehen Backups, Storage, Snapshots, Netzwerkrichtlinien, Monitoring, Herstellersupport, eingespielte Betriebsabläufe und jahrelang gewachsene Annahmen. Das bildet die eigentliche Plattform, und genau das steht auf keinem Werbeplakat.