Wenn Sie VMware seit der Übernahme durch Broadcom verfolgt haben, ist Ihnen vielleicht ein Muster aufgefallen. Und mit „Muster“ meine ich die Art von Muster, die meine Fünfjährige hinterlässt, wenn sie einen Permanentmarker und eine frisch gestrichene Wand entdeckt.
Broadcom nimmt eine Änderung vor. VMware-Kunden sind verärgert. Die Partner bemühen sich, dies zu erklären. Alle passen ihre Migrationspläne an. Und ein paar Monate später machen wir das Ganze noch einmal.
In der neuesten Folge geht es um etwas, von dessen Existenz die meisten VMware-Kunden wahrscheinlich noch nie etwas gehört haben: das VMware Virtual Disk Development Kit, besser bekannt als VDDK.
Das klingt nach etwas, das man tief in einem Entwickler-SDK, drei Ordner tief, vergraben finden würde. Das stimmt. Und es ist auch ziemlich wichtig.
Was genau ist VDDK eigentlich?
VDDK ist eine Sammlung von Bibliotheken, die es Software ermöglicht, auf virtuelle Festplatten von VMware zuzugreifen. Dadurch eignet es sich für Datensicherung, Wiederherstellung, Replikation und Klonen – sowie, wenn auch vielleicht etwas umständlich, für die Migration von Broadcom.
Eine Reihe von Migrationsplattformen hat darauf zurückgegriffen. Microsoft Azure Migrate nutzt VDDK als Teil seines agentenlosen VMware-Migrationsprozesses. Das Migration Toolkit for Virtualization von Red Hat nutzt es. Nutanix Move hat es genutzt. Auch andere Tools, die für die Migration von VMware-Workloads auf KVM-basierte Plattformen entwickelt wurden, haben darauf zurückgegriffen.
Bei Azure Migrate hat VDDK dazu beigetragen, die VMware-Migration relativ reibungslos zu gestalten. Stellen Sie die Azure Migrate-Appliance bereit, gewähren Sie Zugriff auf vCenter, lassen Sie Azure Migrate die Umgebung erfassen und replizieren Sie die virtuellen Maschinen, ohne Migrationsagenten in jedem Gastbetriebssystem installieren zu müssen.
Deshalb ist die jüngste Änderung von Bedeutung.
Broadcom stellt VDDK nicht mehr über den üblichen öffentlichen Download-Prozess zur Verfügung. Red Hat bestätigte Ende August, dass die bisherigen öffentlichen Links nicht mehr funktionierten und Kunden Fehlermeldungen wie „Nicht gefunden“ oder „Zugriff verweigert“ erhielten. Da VDDK weiterhin proprietäre Software von Broadcom ist, können Anbieter wie Red Hat nicht einfach eigene Kopien für ihre Kunden bereitstellen.
Broadcom stellte später klar, dass VDDK selbst nicht verschwunden ist. Ausgewählte Technology Alliance-Partner haben weiterhin Zugriff für lizenzierte Zwecke wie Datensicherung und -wiederherstellung. Broadcom hat zudem argumentiert, dass VDDK nie als allgemeiner Anspruch für Kunden im Rahmen von Migrationen gedacht war.
Streng genommen ist das eine Erklärung.
Das ist auch ein bisschen so, als würde man die Treppe aus einem Hotel entfernen und erklären, dass die Treppe technisch gesehen nie zum Zimmer gehört habe.
Eine hilfreiche Klarstellung.
Ein weiterer Tag, eine weitere Überraschung von VMware
Für sich genommen mag die Einschränkung des Zugriffs auf VDDK wie eine ziemlich langweilige Änderung der Lizenzbedingungen erscheinen. Entwickler-Kit. Lizenzvereinbarung. Partnerprogramm. Da ist nichts Aufregendes dabei.
VMware-Kunden können diese Entscheidung jedoch nicht isoliert betrachten.
Seit der Übernahme von VMware hat Broadcom umfassende Änderungen an den Lizenzbedingungen, den Produktpaketen, den Produktbündeln, dem Partner-Ökosystem, dem Support-Modell und der Preisgestaltung von VMware vorgenommen. Unbefristete Lizenzen sind Abonnements gewichen. Produkte wurden zu größeren Bündeln zusammengefasst. Partner wurden entfernt oder neu eingestuft. Kunden – von kleinen Unternehmen bis hin zu Großkonzernen – haben in den letzten Jahren versucht zu verstehen, was sie bei ihrer nächsten Vertragsverlängerung erwerben werden und wie hoch die Kosten dafür sein werden.
Jede dieser Entscheidungen lässt sich als geschäftliche Entscheidung begründen.
Insgesamt haben sie jedoch zu einem Vertrauensproblem geführt.
Nun gibt es eine weitere Änderung, die dazu führt, dass eine gängige Methode zur Abwanderung von VMware schwieriger anzuwenden ist.
Man kann verstehen, warum Kunden vielleicht die Augenbrauen hochziehen. Möglicherweise beide Augenbrauen. Möglicherweise auch eine Augenbraue der Person, die neben ihnen sitzt.
Das sieht nicht besonders gut aus.
Herzlichen Glückwunsch, wir haben den VMware-Streisand-Effekt erfunden
Das erklärte Ziel von Broadcom mag zwar lediglich darin bestehen, den Vertrieb und die lizenzierte Nutzung seiner Software zu kontrollieren. Das praktische Ergebnis könnte jedoch ganz anders ausfallen.
Es wird wieder über VMware-Migrationen gesprochen.
Sehr viel.
Fachmedien berichten über VDDK. Migrationsanbieter diskutieren Alternativen. Die Konkurrenten von VMware erinnern ihre Kunden an ihre eigenen Migrationstools. Berater veröffentlichen Leitfäden zu anderen Möglichkeiten, Workloads aus dem System zu migrieren. Kunden, die ursprünglich vorhatten, noch einen weiteren Verlängerungszyklus abzuwarten, fragen sich nun, ob sie mit der Ausarbeitung eines Ausstiegsplans beginnen sollten.
Das ist im Grunde genommen die Infrastruktur-Version des Streisand-Effekts.
Man muss nur versuchen, einen Weg bei VMware etwas umständlicher zu gestalten, und schon wollen plötzlich alle darüber reden, VMware den Rücken zu kehren.
Noch wichtiger ist jedoch, dass die Sperrung des öffentlichen Zugangs zu VDDK die Abwanderung von Kunden nicht verhindert. Es ändert lediglich einige der Mittel, mit denen wir sie zum Wechsel bewegen.
Broadcom hat möglicherweise eine der angenehmeren Ausfahrten entfernt.
Sie haben die Autobahn nicht entfernt.
Option 1: Azure Migrate bietet weiterhin agentenbasierte Migration an
Fangen wir mit der naheliegenden Alternative an.
Azure Migrate hat die Migration von VMware-Workloads nicht plötzlich eingestellt.
Microsoft unterstützt sowohl die agentenlose als auch die agentenbasierte VMware-Migration. Die agentenlose Replikation ist nach wie vor die von Microsoft bevorzugte Methode für die meisten VMware-Umgebungen, doch die agentenbasierte Migration bleibt eine unterstützte Alternative, wenn die Voraussetzungen für die agentenlose Replikation nicht erfüllt werden können.
Anstatt VDDK zu verwenden, um die VMware-Festplatten über den Hypervisor zu replizieren, installiert Microsoft seinen Mobility Service im Gastbetriebssystem. Eine Replikations-Appliance sendet die Änderungen anschließend an Azure.
Ist die Installation eines Agenten auf jedem Server genauso elegant wie eine agentenlose Migration?
Nr.
Funktioniert das?
Ja.
Manchmal umfasst die Infrastrukturplanung komplexe architektonische Planung, die Erfassung von Abhängigkeiten, Automatisierung und monatelange sorgfältige Konzeption.
Manchmal heißt es auch einfach: „Na gut. Dann installieren wir den Agenten.“
Beides können gültige technische Strategien sein.
Option 2: Datensicherung und -wiederherstellung sind nach wie vor wichtig
Es gibt außerdem eine Technologie, die IT-Fachleute bereits seit mehreren Jahrzehnten nutzen: das sogenannte Backup.
Vielleicht haben Sie schon davon gehört.
Plattformen wie Veeam, Commvault und andere Backup-Produkte für Unternehmen sind bereits gut auf virtuelle VMware-Maschinen abgestimmt. Microsoft selbst dokumentiert Migrationsoptionen von Drittanbietern für Szenarien, in denen der Standardprozess von Azure Migrate nicht geeignet ist, darunter auch Tools von Veeam und Commvault.
Damit ergibt sich für bestimmte Workloads eine weitere durchaus sinnvolle Migrationsstrategie: den Server sichern, ihn in der Zielumgebung wiederherstellen, ihn überprüfen und schließlich die endgültige Umstellung vornehmen.
Die Stellungnahme von Broadcom selbst ist in diesem Zusammenhang wichtig. Das Unternehmen erklärt, dass autorisierte „Technology Alliance Partners“ weiterhin Zugriff auf VDDK für lizenzierte Backup- und Wiederherstellungszwecke haben. Das bedeutet, dass viele Unternehmen mit ausgereiften VMware-Backup-Umgebungen möglicherweise bereits über einen Teil der Technologie verfügen, die erforderlich ist, um ihre Workloads an einen anderen Ort zu verlagern.
Sichern Sie die Arbeitslast. Stellen Sie sie an einem anderen Ort wieder her. Überprüfen Sie sie. Führen Sie die Umstellung durch.
Herzlichen Glückwunsch.
Wir haben das Umziehen erfolgreich neu erfunden.
Manchmal ist die langweilige Antwort die beste Antwort.
Option 3: Vielleicht sollten wir aufhören, 15 Jahre alte Probleme auf brandneue Azure-VMs zu übertragen
Hier wird es erst richtig interessant.
Viele Gespräche über VMware-Migrationen beginnen mit einer Frage wie dieser:
„Wir haben 200 virtuelle Maschinen. Wie können wir 200 virtuelle Maschinen verschieben?“
Das ist vielleicht die falsche Frage.
Eine viel bessere Frage lautet:
„Warum haben wir immer noch 200 virtuelle Maschinen?“
Der Ausstieg aus VMware bietet eine seltene Gelegenheit, die Workloads zu prüfen, bevor man genau dieselbe Architektur an anderer Stelle neu aufbaut. Der Windows-Server, auf dem IIS läuft, passt möglicherweise besser zu Azure App Service. Eine SQL ServerVM lässt sich möglicherweise sinnvoller als Azure SQL Managed Instance oder Azure SQL Database einsetzen. Der alte Dateiserver könnte in Azure Files, SharePoint oder einer anderen verwalteten Plattform besser aufgehoben sein.
Und dann ist da noch der Anwendungsserver, den niemand versteht.
Jede Migration hat eine.
Er wird in der Regel etwa so benannt: SERVER02-OLD-FINAL-DO-NOT-DELETE.
Es wurde 2014 installiert. Niemand weiß mehr, wer die Anwendung installiert hat. Der ursprüngliche Anbieter existiert nicht mehr. Das Passwort für das Dienstkonto ist möglicherweise älter als einige Ihrer IT-Mitarbeiter.
Das könnte einer weiteren Erörterung bedürfen.
Der springende Punkt ist, dass eine VMware-Migration nicht zwangsläufig bedeutet, jede VMDK-Datei auf einen neuen Hypervisor zu kopieren oder sie in eine AzureVM zu integrieren. Der Ausstieg aus VMware kann der Anstoß sein, Workloads außer Betrieb zu nehmen, Server zu konsolidieren, Datenbanken auf Managed Services zu verlagern, die Identitätsverwaltung zu verbessern, das Netzwerk neu zu gestalten und jahrelange technische Schulden abzubauen.
Das führt langfristig oft zu einem weitaus besseren Ergebnis als eine perfekte „Lift-and-Shift“-Migration im Verhältnis 1:1.
Hier kommt ein Partner ins Spiel
Bei TrustedTech ist es nicht unser Ziel, jeden VMware-Kunden in dasselbe Migrationsmuster zu zwingen.
Manchmal muss man einfach mal raus.
Nun.
Vielleicht rückt Ihre Verlängerungsfrist näher. Vielleicht haben sich Ihre Lizenzkosten geändert. Vielleicht steht eine Erneuerung Ihrer Infrastruktur an. Vielleicht hat die Geschäftsleitung beschlossen, dass das VMware-Experiment seinen natürlichen Abschluss gefunden hat.
Oder vielleicht hat jemand die neueste Pressemitteilung von Broadcom mit siebzehn Fragezeichen an den CIO weitergeleitet.
Das verstehen wir.
Wenn es auf Geschwindigkeit ankommt, haben wir verschiedene Möglichkeiten. Wir können das agentenbasierte Azure Migrate nutzen. Wir können Backup- und Wiederherstellungsfunktionen einsetzen. Wir können Migrationstools von Drittanbietern verwenden. Wir können eine datenbanknative Migration durchführen. Wir können bestimmte Anwendungen neu erstellen, anstatt sie zu migrieren. Wir können sogar mehrere Ansätze innerhalb derselben Umgebung kombinieren.
Es gibt keine Regel, die besagt, dass alle 200 Server auf dieselbe Weise die Ziellinie überqueren müssen.
Eine Migration muss auch nicht so elegant sein, dass sie im Louvre ausgestellt werden könnte. Sie muss sicher, wiederholbar, getestet und für die Arbeitslast geeignet sein.
Wenn Ihre Frist knapp ist, können wir uns nach dieser Frist richten.
Aber wenn wir Zeit haben, machen wir es doch richtig.
Wenn wir mehr Spielraum haben, sieht die Sache schon anders aus.
Anstatt zu fragen: „Wie schnell können wir diese VMware-Server kopieren?“, können wir fragen: „Wie soll diese Umgebung in fünf Jahren aussehen?“
Manche Workloads werden möglicherweise weiterhin als Azure-VMs ausgeführt. Daran ist nichts auszusetzen. Virtuelle Maschinen sind nach wie vor nützlich, und viele Anwendungen müssen keineswegs „modernisiert“ werden, nur damit jemand eine PowerPoint-Folie mit dem Aufkleber „Cloud-nativ“ versehen kann.
Andere Workloads lassen sich möglicherweise sinnvoll auf Azure App Service, Azure SQL, Azure Virtual Desktop, Azure Files, verwalteten Datenbanken, Containern oder anderen Azure-Diensten ausführen.
Wir können uns folgende Themen ansehen: Identitätsmanagement, Vernetzung, Sicherheit, Notfallwiederherstellung, Datensicherung, Serverdimensionierung, Speicherkapazität, Lizenzierung, Hochverfügbarkeit und Betriebskosten.
Wir können auch wichtige Fragen stellen, beispielsweise warum ein Server mit drei aktiven Benutzern 384 GB RAM benötigt.
Es gibt immer einen.
Aus diesem Grund zieht es TrustedTech vor, größere VMware-Ausstiegsprojekte mit einer Bestandsaufnahme und Bewertung zu beginnen. Bevor wir Workloads verlagern, möchten wir verstehen, welche Funktionen sie erfüllen, was von ihnen abhängt, wie viel Kapazität sie beanspruchen, welche Kosten sie verursachen und ob sie in ihrer derzeitigen Form überhaupt noch benötigt werden.
Wenn Sie ein schlechtes Design in Azure migrieren, erhalten Sie lediglich ein schlechtes Design mit einer monatlichen Rechnung.
Möglicherweise beteiligt sich auch Microsoft an den Kosten
Es gibt noch einen weiteren Grund, dies zu planen, bevor jemand an einem Dienstagnachmittag einen Notfall-Umzug ausruft.
Microsoft möchte diese Workloads.
Microsoft investiert weiterhin in Programme, die Kunden bei der Migration und Modernisierung von VMware, Windows Server, SQL Server, Linux und anderer Infrastruktur auf Azure unterstützen. Azure Migrate und Modernize bieten Tools, Partnerunterstützung und Fördermöglichkeiten für förderfähige Migrationsprojekte.
Je nach Größe der Umgebung, dem erwarteten Azure-Verbrauch, den betroffenen Workloads und den aktuellen Microsoft-Programmen können Kunden möglicherweise auch Anspruch auf weitere Anreize oder Endkunden-Investitionsfonds haben.
Die genaue Höhe der Förderung ändert sich im Laufe der Zeit, und es kommt auf die Fördervoraussetzungen an. Es handelt sich nicht um eine unbegrenzte Geldquelle von Microsoft, die auf Ihr Rechenzentrum abzielt.
Leider.
Bei einem geeigneten Projekt können die verfügbaren Fördermittel jedoch einen Teil der Kosten für die Bestandsaufnahme, Planung, Migration oder Modernisierung ausgleichen.
Das wird noch interessanter, wenn wir damit beginnen, herkömmliche VM-Workloads durch native Azure-Dienste zu ersetzen. Microsoft hat ein starkes Interesse daran, Kunden bei der Umstellung auf Azure zu unterstützen, und diese Anreize können die Wirtschaftlichkeit eines Migrationsprojekts mitunter erheblich beeinflussen.
Aus diesem Grund ziehen wir es vor, die Finanzierung zu prüfen, bevor die Migration beginnt.
Nach Abschluss des Projekts festzustellen, dass Microsoft möglicherweise einen Teil der Kosten übernommen hat, ist das Cloud-Äquivalent dazu, nach dem Verlassen von Costco einen Gutschein in der Hosentasche zu finden.
Das tut weh.
Sie müssen nicht in Panik geraten. Aber Sie sollten wahrscheinlich einen Plan haben.
Die Entscheidung von Broadcom bezüglich VDDK ist unpraktisch. Bei manchen Migrationsprojekten kann sie sogar sehr unpraktisch sein.
Es ist keine Mauer.
Azure Migrate unterstützt weiterhin die agentenbasierte Migration. Backup- und Wiederherstellungsplattformen bieten weitere Migrationspfade. Tools von Drittanbietern stehen weiterhin zur Verfügung. Die Methoden zur Anwendungs- und Datenbankmigration bleiben unverändert. Und in vielen Fällen macht die Modernisierung eine Migration der ursprünglichen virtuellen VMware-Maschine gänzlich überflüssig.
Die größere Frage ist, was diese Entscheidung bedeutet.
VMware-Kunden haben über Jahre hinweg Änderungen bei Lizenzen, Preisen, Produktpaketen und Partnern hingenommen. Die Einschränkung des Zugriffs auf eine Komponente, die häufig von Migrationswerkzeugen genutzt wird, ist ein weiterer Grund, warum Unternehmen ihre langfristige VMware-Strategie überdenken sollten, bevor ihr nächster Verlängerungstermin ansteht.
Die Frage sollte nicht lauten: „Müssen wir VMware schon morgen aufgeben?“
Für manche Unternehmen könnte der Verbleib bei VMware nach wie vor die richtige Lösung sein.
Die bessere Frage lautet:
„Wie sieht es für uns in den nächsten drei bis fünf Jahren aus, wenn wir bei VMware bleiben, und sind wir damit einverstanden?“
Bei TrustedTech ist es unsere Aufgabe, unseren Kunden dabei zu helfen, diese Frage zu beantworten.
Wenn der Einsatz von VMware aus technischer und finanzieller Sicht weiterhin sinnvoll ist, können wir dazu beitragen, dass diese Entscheidung auf einer soliden Architektur und konkreten Zahlen basiert.
Sollte die Antwort eine vollständige Exfiltration lauten, stehen uns mehrere Möglichkeiten zur Verfügung, dies auch unter Zeitdruck zu bewerkstelligen.
Und wenn wir genügend Zeit haben, würden wir viel lieber einen Migrationsplan mit minimalen Ausfallzeiten entwickeln, der auch technische Schulden abbaut, die Arbeitslasten sinnvoll modernisiert, Azure-native Dienste dort nutzt, wo sie einen Mehrwert bieten, und alle verfügbaren Fördermittel von Microsoft in Anspruch nimmt.
Vielleicht bedeutet das, dass man ein paar Azure-Dienste in die Architektur einbindet.
Vielleicht bedeutet das, die gesamte Umgebung auf Azure zu verlagern und es dabei zu belassen.
So oder so: Broadcom hat möglicherweise einen Migrationsweg erschwert.
Es gibt noch viele weitere.
Und mittlerweile ist es in der Branche fast schon zu einer Art Hobby geworden, regelmäßig neue Wege zu finden, um von VMware wegzukommen.
Wenigstens hält es uns von der Straße fern.
Quellen und weiterführende Literatur
- Network World: „Broadcom behindert VMware-Migration durch Sperrung wichtiger SDK-Downloads“, 11. September 2026. Der Artikel befasst sich mit der Einschränkung öffentlicher VDDK-Downloads durch Broadcom und nennt Azure Migrate, das Red Hat Migration Toolkit, Nutanix Move sowie weitere Migrationsprodukte, die das VDDK nutzen.
- Network World: Zeitleiste zu Produkten, Dienstleistungen und Support von VMware unter Broadcom. Bietet einen umfassenderen Überblick über die Änderungen, die Broadcom seit der Übernahme an den VMware-Produkten, der Lizenzierung, den Dienstleistungen und dem Support vorgenommen hat.
- Red Hat-Kundenportal: „VMware-VDDK-Images für das Migration Toolkit for Virtualization können nicht heruntergeladen werden.“ Hier wird bestätigt, dass VDDK-Images für Endbenutzer nicht mehr über den üblichen öffentlichen Download-Prozess verfügbar sind, und erläutert, dass Red Hat das proprietäre Paket von Broadcom nicht weiterverbreiten darf.
- Microsoft Learn: „Agentenlose und agentenbasierte Migrationsmethoden in Azure Migrate“. Beschreibt die von Microsoft unterstützten Ansätze für die VMware-Migration und bestätigt, dass die agentenbasierte Replikation weiterhin verfügbar ist, wenn die Voraussetzungen für die agentenlose Migration nicht erfüllt werden können.
- Microsoft Learn: „Agentenbasierte Migration im Migration and Modernization Tool“. Erläutert die Architektur, die für die Migration von VMware-VMs über den Microsoft Mobility Service und die Replikations-Appliance verwendet wird.
- Microsoft Learn: „Migration von VMware vSphere-VMs nach Azure mithilfe der agentenbasierten Migration.“ Die Schritt-für-Schritt-Anleitung von Microsoft zur Migration virtueller Maschinen von VMware und der Azure VMware Solution nach Azure mithilfe der agentenbasierten Replikation.
- Microsoft Learn: „Migration von VMware-VMs nach Azure mithilfe der agentenlosen Migration.“ Die Dokumentation von Microsoft zur agentenlosen Migration von VMware über Azure Migrate, einschließlich der Appliance und des Replikationsprozesses.
- Microsoft Azure: Azure Migrate und Modernize. Das aktuelle Programm von Microsoft für Bestandsaufnahmen, Migration, Modernisierung, Partnerprojekte und entsprechende Migrationsanreize.
