Broadcom sperrt VDDK-Download: Migrationen und Backup-Tools betroffen
Broadcom hat den öffentlichen Zugriff auf die Downloadseite des VMware Virtual Disk Development Kit gesperrt. Bereits heruntergeladene Versionen laufen weiter, neue Downloads gibt es nicht mehr. Betroffen sind vor allem Migrationsprojekte weg von VMware und Drittanbieter-Werkzeuge, die agentenlos auf VMDK-Dateien zugreifen.
Ein Migrationsprojekt bleibt an einer Stelle hängen, an der es sonst nie hängt: beim Download einer Bibliothek. Die Anleitung verlangt das VMware Virtual Disk Development Kit, kurz VDDK, der Link führt auf das Broadcom-Portal, und das Portal antwortet mit einer Fehlermeldung. Kein Login-Hinweis, kein Ersatzpfad, kein Hinweis auf eine Nachfolgeversion. Damit steht ein Arbeitsschritt still, der in vielen Dokumentationen als selbstverständliche Voraussetzung geführt wird.
Reagieren muss jetzt vor allem, wer aktiv von VMware weg migriert oder wer eine Backup- beziehungsweise Migrationslösung einsetzt, die das VDDK erst zur Laufzeit nachlädt. Wer in einer bestehenden, lizenzierten VMware-Umgebung bleibt und dessen Sicherungssoftware das VDDK bereits mitgebracht hat oder lokal vorhält, ist kurzfristig nicht betroffen. Die vorhandenen Kopien funktionieren weiter. Es gibt schlicht keine Downloads mehr, weder für neue noch für bestehende Versionen.
Was ist passiert?
Broadcom hat den öffentlichen Zugriff auf die Webseite gesperrt, von der sich das VMware Virtual Disk Development Kit herunterladen ließ. Gemeldet hat das Günter Born in seinem Blog Borns IT-Blog am 11. September 2026. Die Downloadseiten für VDDK 8 und VDDK 9 sowie die Startseite geben seitdem eine allgemeine Fehlermeldung aus. Laut den vorliegenden Berichten gab es im Vorfeld keine offizielle Mitteilung von Broadcom.
Das VDDK ist keine Endanwendersoftware, sondern eine Bibliothek. Sie ermöglicht es Drittanbieter-Software, virtuelle VMware-Festplatten von außerhalb des Hypervisors zu lesen. Genau dieser Zugriff ist die Grundlage für agentenlose Sicherung und für viele Migrationswerkzeuge: Sie müssen den Inhalt einer VMDK-Datei auslesen können, ohne in jedem Gastsystem einen Agenten zu installieren. Fällt die Bezugsquelle weg, fällt nicht die Funktion weg, sondern die Möglichkeit, sie überhaupt erst bereitzustellen.
Die Sache hat einen Vorlauf. Ein Nutzer hatte den fehlenden Download bereits im August 2026 in einem Reddit-Beitrag beklagt. Das ist kein Faktenbeleg, aber ein Hinweis darauf, dass die Sperre nicht erst mit der Berichterstattung begann. Der Dienstleister ShapeBlue hat den Sachverhalt in einem eigenen Blogpost ausführlicher dargestellt. Auch die offizielle Broadcom-Entwicklerseite zum VDDK war zum Zeitpunkt unserer Prüfung nicht regulär erreichbar und lieferte einen Serverfehler. Das ist kein Nebenschauplatz, sondern selbst Teil der Meldung: Der dokumentierte Einstiegspunkt führt ins Leere.
Für wen ist das relevant?
Die Betroffenheit hängt nicht davon ab, ob VMware im Einsatz ist, sondern davon, ob in der eigenen Werkzeugkette irgendwo ein Schritt steht, der das VDDK frisch beziehen muss. Zwei konkret benannte Fälle sind bereits dokumentiert.
- Microsoft-Azure-Kunden: Laut itsfoss.com weist die Dokumentation zu Azure Migrate Administratoren an, VDDK 8.0 oder 9.0 vom Broadcom-Portal herunterzuladen, um die agentenlose Migration nutzen zu können. Fällt der Download weg, fällt dieser Anleitungsschritt aus.
- Red-Hat-Kunden: Ebenfalls laut itsfoss.com heißt es in einem Support-Hinweis, Kunden erhielten beim Versuch, auf die öffentlichen VDDK-Download-Links zuzugreifen, die Fehlermeldungen "Nicht gefunden" oder "Zugriff verweigert". Red Hat kann das Kit weder hosten noch weiterverbreiten und sucht nach einer Alternative.
- Migrationsprojekte weg von VMware: Wer Arbeitslasten auf eine andere Virtualisierungsplattform überführen will, trifft den Engpass am ehesten, weil genau diese Werkzeuge das VDDK typischerweise als externe Abhängigkeit einbinden.
- Drittanbieter-Backup mit agentenlosem Zugriff: Sicherungslösungen, die VMDK-Dateien von außen lesen, brauchen dieselbe Bibliothek. Entscheidend ist, ob sie bereits vorliegt oder erst beschafft werden muss.
- Nicht akut betroffen: Bestehende, lizenzierte VMware-Umgebungen mit laufender, bereits installierter Sicherung. Dort ändert sich im Tagesbetrieb zunächst nichts.
Der lizenzrechtliche Kern macht das Problem größer, als ein blockierter Link vermuten lässt. Laut einer Darstellung von Uranium Backup ist der Zugriff auf die VDDK-API nur mit einer ESXi-Lizenz zulässig, und das VDDK darf nicht gemeinsam mit Software vertrieben werden. Das bedeutet: Drittanbieter dürfen es nicht einfach mitliefern. Diese Einordnung ist eine Darstellung von Uranium Backup, keine offizielle Aussage von Broadcom. Sie erklärt aber, warum ein naheliegender Ausweg, das Kit einfach selbst zu spiegeln oder mitzuliefern, für Anbieter nicht ohne Weiteres gangbar ist.
Wie kritisch ist das?
Es handelt sich nicht um eine Sicherheitslücke, sondern um eine Produkt-, Lizenz- und Verfuegbarkeitsentscheidung eines Herstellers. Es gibt keinen Patch, den man einspielen könnte, und keinen Angriffspfad, den man schließen müsste. Die Dringlichkeit hängt allein davon ab, wie stark die eigene Werkzeugkette an dem gesperrten Download hängt. Die folgende Tabelle ordnet die typischen Szenarien ein.
| Szenario | Abhängigkeit vom VDDK | Aktuelle Auswirkung |
|---|---|---|
| Laufende VMware-Umgebung, Backup-Software hat VDDK bereits lokal | Vorhanden, kein Neubezug nötig | Kurzfristig keine Auswirkung, Sicherung läuft weiter |
| Neuinstallation oder Neuaufbau eines Backup-Servers | Neubezug erforderlich, falls nicht im Paket enthalten | Installation kann an dem fehlenden Download scheitern |
| Agentenlose Migration über Azure Migrate | Dokumentation verlangt VDDK 8.0 oder 9.0 vom Broadcom-Portal | Dokumentierter Arbeitsschritt nicht mehr ausführbar |
| Migration mit Werkzeugen aus dem Red-Hat-Umfeld | Externe Abhängigkeit, kein Hosting durch den Hersteller erlaubt | Support meldet Fehler beim Zugriff, Alternative wird gesucht |
| Wechsel auf eine andere Virtualisierungsplattform | Je nach Werkzeug hoch | Projektplanung und Zeitplan müssen geprüft werden |
| Umgebung ohne agentenlosen VMDK-Zugriff | Keine | Nicht betroffen |
Offen und ungeklärt bleibt der Kern der Sache: Broadcom hat sich dazu nach der vorliegenden Berichtslage nicht offiziell geäußert. Ob und in welcher Form der Zugang künftig wieder geöffnet oder auf lizenzierte Kunden beschränkt wird, ist unklar. Wer daraus jetzt eine dauerhafte Strategie ableiten will, arbeitet mit Annahmen, nicht mit Zusagen. Genau deshalb ist der sinnvollste Schritt derzeit Bestandsaufnahme und Dokumentation, nicht der schnelle Umbau.
Was sollten Admins jetzt tun?
Die Reihenfolge ist wichtig. Zuerst klären, ob es überhaupt ein eigenes Problem ist. Erst danach handeln.
- Prüfen, ob die eigene Backup- und Migrationskette das VDDK überhaupt braucht. Herstellerdokumentation und Installationsanleitung der eingesetzten Lösung durchsehen. Zentrale Frage: Wird das Kit mitgeliefert, liegt es lokal vor, oder wird es zur Installationszeit vom Broadcom-Portal geladen?
- Vorhandene VDDK-Kopien sichern und dokumentieren. Auf den Backup- und Migrationsservern nachsehen, welche Version installiert ist, und den Fundort samt Versionsnummer festhalten. Eine Kopie an einem geschützten, dokumentierten Ort ablegen. Dabei die Lizenzlage beachten: Weiterverbreitung ist nach der geschilderten Darstellung nicht zulässig, die eigene Nutzung im lizenzierten Rahmen bleibt davon unberührt.
- Hersteller-Support der eingesetzten Backup- oder Migrationslösung kontaktieren. Konkret fragen, wie der Anbieter mit der Situation umgeht, ob künftige Versionen das Kit enthalten und welcher Bezugsweg für Neuinstallationen vorgesehen ist. Die Antwort schriftlich festhalten.
- Laufende und geplante Migrationsprojekte neu bewerten. Prüfen, ob ein geplanter Umzug an dem gesperrten Download hängt, und den Zeitplan entsprechend anpassen, bevor ein Wartungsfenster daran scheitert.
- Lizenzlage prüfen. Bestehende ESXi- und Support-Verträge sichten und intern festhalten, welche Nutzung davon abgedeckt ist. Das ist auch die Grundlage für jede Rückfrage beim Hersteller.
- Neuinstallationen vorher testen. Einen Neuaufbau des Backup-Servers nicht ungeprüft in einem engen Wartungsfenster planen, sondern den Installationsweg vorher in einer Testumgebung durchspielen.
- Keine dubiosen Download-Quellen nutzen. Kopien der Bibliothek aus unbekannten Quellen sind weder lizenzrechtlich noch sicherheitstechnisch vertretbar. Der Bezug gehört über den Hersteller oder den eigenen Anbieter geklärt.
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen ist die eigentliche Lehre weniger technisch als strukturell. Eine einzelne, extern gehostete Datei war jahrelang stillschweigende Voraussetzung für einen Großteil der Sicherungs- und Migrationswerkzeuge rund um VMware. Solange sie verfügbar war, ist sie niemandem aufgefallen. Jetzt zeigt sich, dass ein Hersteller diese Voraussetzung ohne Vorlauf entziehen kann.
Praktisch heißt das: Abhängigkeiten der eigenen Backup-Kette gehören dokumentiert, nicht nur die Backup-Jobs selbst. Wer aufschreibt, welche externen Komponenten eine Wiederherstellung oder ein Neuaufbau voraussetzt, merkt solche Änderungen früh und nicht erst im Ernstfall. Ebenso gehört die Frage in jede Migrationsplanung, welche Schritte an Ressourcen hängen, die man selbst nicht kontrolliert.
Der Schritt trifft vor allem Organisationen, die von VMware weg migrieren wollen, sowie Backup- und Migrationswerkzeuge von Drittanbietern, die agentenlos auf VMDK-Dateien zugreifen. Panik ist nicht angebracht, laufende Umgebungen arbeiten weiter. Wer aber einen Plattformwechsel im Zeitplan hat, sollte diesen Punkt jetzt prüfen und nicht erst kurz vor dem Umzugstermin.
Passende Anleitungen auf S-EDV
- Proxmox VE installieren und grundkonfigurieren zeigt, wie eine alternative Virtualisierungsplattform aufgesetzt wird, wenn ein Wechsel im Raum steht.
- Veeam Backup und Replication: Grundlagen und erster Job hilft beim Nachvollziehen, wie die eigene Sicherungskette aufgebaut ist und wo externe Komponenten einsteigen.
- Proxmox Backup Server mit S3 als unveränderliches Offsite-Ziel beschreibt eine Sicherungsstrategie, die unabhängig vom VMware-Werkzeugkasten funktioniert.
