Broadcom VDDK-Zugang erschwert den VMware-Ausstieg

Teams, die eine VMware-Migration planen, stehen vor einem neuen Abhängigkeitsproblem. Der öffentliche Zugang zum VMware Virtual Disk Development Kit (VDDK) hat sich im August 2026 verändert. Mehrere dokumentierte Downloadpfade für das VDDK funktionierten plötzlich nicht mehr oder wurden restriktiv beschränkt. Da Backup- und Migrationswerkzeuge das VDDK nutzen, um virtuelle Festplatten von VMware effizient auszulesen, sollten Sie diesen Schritt umgehend überprüfen, falls Ihr Ausstiegsplan vorsieht, das VDDK einfach zu Projektbeginn herunterzuladen.

Vor dem Verfassen dieses Beitrags wurden Berichte verschiedener Migrationsdienstleister und Diskussionen in der Broadcom-Community ausgewertet. Die Faktenlage belegt eindeutig, dass der öffentliche Zugriff geändert wurde und Anwender auf fehlerhafte oder gesperrte Downloadseiten stießen. Dies rechtfertigt jedoch keine spekulativen Rückschlüsse auf Broadcoms Absichten. Von vorsätzlicher Sabotage zu sprechen, wäre ohne entsprechende offizielle Belege unseriös.

Was ist das VMware VDDK und warum ist es wichtig?

Das VMware Virtual Disk Development Kit ist eine Sammlung von Bibliotheken und Programmierschnittstellen (APIs) für den direkten Zugriff auf virtuelle Festplattendateien von VMware. Produkte für Backup, Replikation, Konvertierung, Disaster Recovery und Migration greifen darauf zurück, um VM-Festplatten zu verarbeiten, ohne jede virtuelle Maschine wie einen physischen Server behandeln zu müssen.

Damit bildet das VDDK eine grundlegende Infrastrukturkomponente. Die meisten Administratoren beschäftigen sich im Betriebsalltag selten mit solchen Basiskomponenten. Sie fallen erst dann auf, wenn sie nicht mehr verfügbar sind.

Ein Migrationswerkzeug wirbt vielleicht mit einem unkomplizierten Wechsel von VMware zu KVM, benötigt unter der Haube jedoch weiterhin einen offiziell unterstützten Weg, um die Quelldatenträger auszulesen. Setzt diese Methode das VDDK voraus und lässt sich die geforderte Version nicht beschaffen, scheitert das Migrationsprojekt bereits, bevor die erste VM verschoben wurde. Das ist ein echtes Projektrisiko und weit mehr als eine bloße Unannehmlichkeit beim Download.

Was änderte sich beim VDDK-Zugang im August 2026?

Migrationsanbieter berichteten, dass Broadcoms öffentliche VDDK-Downloadseiten um den 25. August 2026 herum ihren Dienst versagten. ShapeBlue dokumentierte Seitenfehler bei Workflows zur Migration von VMware auf KVM, während Platform9 von eingeschränktem Zugang sprach und Kunden aufforderte, Ausweichpfade zu planen.

Beiträge in der Broadcom-Community zeigen dieselben praktischen Symptome auf Kundenseite: Anwender folgten den offiziellen Links und konnten das benötigte Toolkit nicht mehr herunterladen.

Gleichzeitig bleibt das VDDK eine aktive Abhängigkeit moderner Migrationsprodukte. So kündigte Oracle beispielsweise im August 2026 die Unterstützung für das VDDK 8.0.3 in Oracle Cloud Migrations an. Das verdeutlicht, wie wichtig ein geregelter Zugang ist: Ein aktueller Migrationsablauf kann von einer exakten Toolkit-Version abhängen, selbst wenn das übergeordnete Ziel darin besteht, VMware den Rücken zu kehren.

Kurz gesagt: Die Verfügbarkeit hat sich gewandelt, offizielle Links wurden unbrauchbar oder für bestimmte Nutzergruppen gesperrt. Migrationsverantwortliche dürfen daher keinesfalls davon ausgehen, dass der Bezug des VDDK ein Selbstläufer ist.

Hat Broadcom das VDDK entfernt, um Migrationen zu verhindern?

Es liegen nicht genügend öffentliche Beweise vor, um Broadcoms Beweggründe als gesicherte Tatsache darzustellen. Manche Anbieter und Anwender werten die Einschränkung als Versuch, Kundenbindung künstlich zu erzwingen, da das VDDK genau dann benötigt wird, wenn Daten aus VMware heraus migriert werden sollen. In einer technischen Analyse müssen Ursache und vermutete Absicht jedoch klar getrennt bleiben.

Der messbare Effekt steht fest: Bestimmte Migrationsprozesse wurden erschwert, weil eine zuvor frei zugängliche Komponente nicht mehr über denselben Pfad beziehbar war. Die genauen Hintergründe ließen sich nur durch offizielle Erklärungen seitens Broadcom oder belastbare interne Dokumente belegen.

Für die Migrationsplanung spielt das Motiv letztlich eine untergeordnete Rolle; entscheidend ist die praktische Reaktion. Wenn ein Werkzeug das VDDK voraussetzt, müssen Sie vor Beginn des Migrationsfensters verbindlich prüfen, ob Sie den geforderten Build mit Ihrem Firmenkonto und Ihren Lizenzansprüchen legal und verlässlich herunterladen können. Testen Sie das während der Konzeptionsphase, denn das eigentliche Umstellungswochenende ist der denkbar schlechteste Zeitpunkt für Überraschungen.

Welche Migrationsprojekte sind besonders gefährdet?

Besonders exponiert sind Projekte, die auf agentenlose Festplattenkonvertierung oder auf Werkzeuge setzen, die fest um das VDDK herum aufgebaut sind. Die konkrete Auswirkung hängt vom gewählten Zielsystem und der eingesetzten Migrationssoftware ab.

Ein Konverter von VMware auf KVM nutzt das VDDK oft für den performanten Lesezugriff auf Quelldatenträger. Eine Backup-Plattform benötigt es zur Sicherung auf Image-Ebene, ein Replikationswerkzeug für den kontinuierlichen Datenabgleich. Manche Cloud-Migrationsdienste setzen das VDDK schlicht als Voraussetzung voraus, die der Kunde selbst bereitstellen muss.

Wenn in Ihrem Betriebshandbuch der Schritt „VDDK herunterladen" steht, definieren Sie diesen als formale Projektabhängigkeit mit Verantwortlichem, exakter Versionsnummer, Prüfsumme, Lizenzberechtigung und Notfallplan.

Wenden Sie dieselbe Sorgfalt auf Firmware, Treiber, Konvertierungs-Appliances, Lizenzen, Zertifikate und API-Zugangsdaten an. Jede Migration gleicht einer Kette, und sie reißt erfahrungsgemäß an dem Glied, das im Vorfeld niemand getestet hat.

Die Mr.PlanB-Vergleichsübersicht hilft bei der Evaluierung alternativer Plattformen, doch die Auswahl des Zielsystems muss die konkrete Migrationsmechanik zwingend einschließen. Eine Plattform mag im Dauerbetrieb überzeugen, erweist sich jedoch als schlechtes Ziel, wenn der Weg dorthin instabil ist.

Lässt sich eine VMware-Migration auch ohne VDDK durchführen?

Ja. Das VDDK ist nützlich, stellt aber nur eine von mehreren Möglichkeiten dar, virtuelle Maschinen zu migrieren. Die Alternativen hängen von der tolerierbaren Ausfallzeit, dem Gastbetriebssystem, der Speicherarchitektur, dem Ziel-Hypervisor und den verfügbaren Tools ab.

Eine Option ist die Migration auf Ebene des Gastbetriebssystems. Dabei wird ein Agent oder Replikationsdienst innerhalb der VM installiert, der Anwendungsdaten oder Speicherblöcke auf ein neues Zielsystem spiegelt, woraufhin die Umstellung erfolgt. Dies eignet sich hervorragend für Workloads mit nativen Replikationsmechanismen, etwa Datenbank-Replikation oder Dateisynchronisierung.

Eine weitere Möglichkeit besteht in Export und Konvertierung. Je nach Umgebung exportieren Sie OVF- oder OVA-Pakete, kopieren virtuelle Festplatten oder nutzen Konverter, die andere Zugriffsmethoden unterstützen. Dieser Weg kann langsamer sein und ein größeres Wartungsfenster erfordern.

Speicherbasierte Migrationen bieten sich an, wenn Quell- und Zielumgebung auf dieselbe Storage-Technologie zugreifen oder Speicher-Arrays Daten unabhängig vom Hypervisor synchronisieren können.

Einige Zielplattformen bringen eigene Migrationstools mit. Prüfen Sie deren technische Voraussetzungen im Detail: Auch hinter einem komfortablen Assistenten kann sich im Hintergrund eine Abhängigkeit vom VDDK verbergen.

Wenn Proxmox VE Ihr Ziel ist, beginnen Sie mit der aktuellen Proxmox-Plattformübersicht und bauen Sie eine repräsentative Testmigration auf. Verlassen Sie sich nicht auf Online-Videos, die eine einzelne Standard-VM unter Laborbedingungen konvertieren, die nicht zu Ihrem Speicher- und Netzwerkdesign passen.

Was sollten Sie vor einer VMware-Migration archivieren?

Sichern Sie Installationsmedien, VDDK-Builds, Prüfsummen, Lizenzdateien, Dokumentationen, Konvertierungstools und Skripte, von denen Ihr Migrationsplan abhängt, unter Beachtung der geltenden Lizenzbedingungen. Dokumentieren Sie präzise, woher jede Datei stammt und welche Versionen der Quellumgebung sie unterstützt. Das sichert die Reproduzierbarkeit; ein sechsmonatiges Migrationsprojekt darf nicht von der dauerhaften Erreichbarkeit einer externen Webseite abhängen.

Halten Sie zudem die exakten VMware-Versionsstände der Quellumgebung fest. Die Kompatibilität des VDDK variiert je nach vSphere- und ESXi-Build; ein Tool, das für einen bestimmten Build freigegeben wurde, verhält sich unter einem anderen unter Umständen abweichend.

Verwalten Sie diese Artefakte zentral in Ihrem Versionskontrollsystem statt auf dem Notebook eines einzelnen Technikers. Sollte das Projekt unterbrochen und später wieder aufgenommen werden, muss das nachfolgende Team die getestete Toolchain lückenlos wiederherstellen können.

Diese Praxis empfiehlt sich generell: Hersteller überarbeiten Portale, ändern Produktnamen, stellen Anmeldesysteme um und passen Download-Richtlinien an. Ein Migrationsprojekt gewinnt erheblich an Stabilität, wenn kritische Abhängigkeiten als feste Projektartefakte gespeichert und nicht als flüchtige Lesezeichen verwaltet werden.

Macht dies Proxmox oder KubeVirt attraktiver?

Offene Migrationswege gewinnen dadurch an Attraktivität, auch wenn ein quelloffenes Zielsystem den Ausstieg aus der proprietären Quelle nicht automatisch erleichtert. Sowohl Proxmox als auch KubeVirt basieren auf offenen Virtualisierungsstandards, doch die Daten müssen zunächst die VMware-Grenze passieren.

Der vMotion-Lernkurven-Artikel unterstreicht einen wesentlichen Punkt: Der Abschied von VMware umfasst weit mehr als das bloße Konvertieren von VM-Festplatten. Teams müssen neue Betriebskonzepte, Backup-Routinen, Monitoring-Lösungen, Netzwerkkonzepte und Notfallhandbücher etablieren.

Die Zugangsbeschränkungen beim VDDK sind ein zusätzlicher Ansporn, frühzeitig zu handeln. Je länger Sie warten, desto größer ist das Risiko, dass Verträge, Download-Portale oder veraltete Tool-Abhängigkeiten auf den kritischen Pfad Ihres Projekts geraten.

Was vor der Freigabe eines VMware-Ausstiegsplans zu tun ist

Verlangen Sie vom Projektteam den praktischen Nachweis des Migrationspfads mit exakt den Werkzeugen und Versionen, die für den Produktivbetrieb vorgesehen sind. Laden Sie alle Voraussetzungen vorab herunter, verifizieren Sie Lizenzansprüche, dokumentieren Sie Prüfsummen und konvertieren Sie reale Test-Workloads, bevor die Geschäftsführung ein fixes Umstellungsdatum festlegt.

Entwerfen Sie stets mindestens einen Ausweichpfad, der nicht auf dieselbe Zugriffsmethode angewiesen ist. Dieser Pfad mag langsamer sein oder längere Ausfallzeiten verlangen, doch ein bekannter, planbarer Ausweichweg ist weitaus wertvoller, als am Umstellungswochenende festzustellen, dass das primäre Werkzeug eine gesperrte Komponente anfordert.

Wird das Migrationswerkzeug vollständig vom Hersteller betrieben und garantiert dieser vertraglich die Bereitstellung aller erforderlichen VMware-Komponenten, lassen Sie sich diese Zusicherung in einem Pilotprojekt belegen und fixieren Sie die Verantwortung schriftlich.

Die Entwicklungen rund um das VDDK verdeutlichen, dass Sie erst dann wissen, wie viele infrastrukturelle Optionen Sie tatsächlich besitzen, wenn Sie versuchen, diese in der Praxis zu nutzen. Eine Migrationsoption, die auf einer Datei basiert, die Sie nicht herunterladen können, ist in Wahrheit keine tragfähige Option.