OpenVDDK: was der freie Ersatz für VMwares VDDK wirklich trägt

Ende August 2026 hat Broadcom die öffentlichen Download-Seiten für VMwares Virtual Disk Development Kit entfernt, ohne Ankündigung und ohne Ersatzweg. ShapeBlue hat am 25.08.2026 dokumentiert, dass jede VDDK-Pfadvariante auf dem Broadcom-Portal nur noch eine Fehlerseite zurückgibt, geprüft aus Europa und über Exit-Knoten in den USA, Brasilien, Finnland und Japan. Seitdem enden die Installationsanweisungen von virt-v2v, nbdkit und dem VMware-Import von Apache CloudStack auf einem Link ins Leere. Der Cloud-Architekt Andrija Panić hat die betroffene Bibliothek daraufhin neu geschrieben.

OpenVDDK ist eine unabhängige, quelloffene Neuentwicklung der VMware-Bibliothek libvixDiskLib.so.8.0.3, also jener Schicht, über die Backup- und Migrationswerkzeuge virtuelle VMware-Platten von außen lesen. Sie baut als gleichnamige Bibliothek mit denselben Funktionen und Symbolversionen, weshalb vorhandene Werkzeuge wie virt-v2v oder nbdkit die Datei austauschen können, ohne selbst angepasst zu werden. Geschrieben wurde sie nach eigener Aussage im Clean-Room-Verfahren, ohne Code von VMware. Sie ist auf Lesezugriffe beschränkt.

Was im Repository belegt ist

Das Repository openvddk/openvddk ist offen und lässt sich nachmessen. Stand 11.11.2026:

Die Kompatibilitätsmatrix ist der aufschlussreichste dieser Belege, weil sie negative und positive Einträge gleichbehandelt. Getestet ist AlmaLinux 9.8, Debian 13 und Ubuntu 24.04 als Leser. Nicht getestet sind vSAN, vVols und Fibre Channel. vSphere 6.5 und älter sind ausdrücklich ausgeschlossen, der SAN-Transport ist nicht implementiert. Die 43 öffentlichen Funktionen der VDDK 8.0.3 sind einzeln mit Status aufgeführt, inklusive derjenigen, die das Projekt noch gar nicht angeschaut hat.

Wo die Lücke sitzt

Read-only ist eine bewusste Entscheidung, festgehalten im Decision Record D-0027. Write, WriteAsync, WriteMetadata sowie Shrink und Defragment liegen dauerhaft außerhalb des Umfangs. Für eine Migration reicht das, weil sie die Quelle liest und das Ziel mit eigenem Code schreibt. Für einen Rückspielweg über dieselbe Bibliothek reicht es nicht, und genau den brauchte eine Sicherungskette, die auf VDDK baut.

Ein zweiter Punkt fehlt in den Meldungen über das Projekt fast immer: OpenVDDK bildet die Schnittstelle von VDDK 8.0.3 nach, die von VDDK 9.0 bleibt offen. Im Issue-Tracker läuft dazu Issue 3 über Scheibenschreibzugriff und die Changed-Area-Funktionen der neueren Linie. Werkzeuge, die gegen 9.0 gebaut sind, haben davon erst einmal nichts.

Der offene Fehler auf ESXi 7.0 GA

Am 07.11.2026 hat ein Betreiber unter dem Namen adminsyspro Issue 1 eröffnet. Sein Aufbau ist ein typischer Migrationsaufbau: nbdkit mit dem VDDK-Plugin auf einem Proxmox-VE-Knoten, das die Platte einer VM direkt über NBDSSL von einer ESXi-Host-Adresse zieht, ohne vCenter dazwischen. Die Node läuft auf ESXi 7.0.0 GA, Build 15843807. Jeder Versuch schlägt mit bad frame magic 0x4 fehl, die Gegenstelle baut die NFC-Sitzung nach dem Handshake wieder ab. Der Melder hat den Verkehr mitgeschnitten, das Problem auf die Ressourcenpool-Abfrage eingegrenzt und einen Patch mitgeliefert.

Der Maintainer hat am 08.11.2026 geantwortet und die Ursache bestätigt: 6.7 antwortet im NFC mit Version 2, 7.0.3 mit 9, 8.0 mit 11 und 9.1.1 mit 12. OpenVDDK schickt Features und die Ressourcenpool-Abfrage ab Version 9, bei 7.0 GA gehört sie dort nicht hin. Der Fix kommt in 0.7.5. Ebenso festgehalten hat der Autor, dass er 7.0 GA erst dann verifiziert nennt, wenn ein echter 7.0-GA-Host mitgelaufen ist; die Builds zwischen GA und Update 3 erwartet er auf demselben Weg, getestet hat er sie nicht.

Hier entscheidet sich der Einsatz. Die Matrix nennt 7.0.3, und wer eine ungepatchte 7.0er-Node ohne vCenter erwischt, läuft in einen offenen Fehler. Auf die Idee, ESXi 7.0 GA ohne vCenter anzusprechen, kommt man in einem Migrationsprojekt vor allem dann, wenn das vCenter längst abgeschaltet ist und nur noch die Nodes da sind.

Die Messwerte, mit ihrem Maßstab

Die Projektseite von OpenVDDK bringt Zahlen gegen VMwares Bibliothek. Sie stehen dort mit ihrer Bedingung, und wir haben sie nicht nachgemessen. Wer sie zitiert, muss den Maßstab mitschicken.

Die vierte Zeile stammt aus derselben Quelle und nennt eine Konstellation, in der OpenVDDK langsamer ist. Zwei weitere stehen daneben: mit vier Lesern einer Platte liegen beide Bibliotheken gleichauf, und beim serienweisen Lesen über iSCSI-VMFS mit MTU 1500 war VMwares Bibliothek rund drei Prozent vorn. Die deutlicheren Unterschiede hängen außerdem an einem Detail, das der Autor offen ausbreitet. VMwares Bibliothek macht beim Platten öffnen vier Namensauflösungen, und in seinem Labor wartete jede davon fünf Sekunden auf einen nicht antwortenden DNS-Server. Das allein erklärt einen großen Teil der 19 Sekunden.

Gemessen wird mit V2K Migrate, einem Migrationswerkzeug desselben Autors, das als geschlossene Private Beta läuft und sich nicht nachprüfen lässt. Die Datenidentität bleibt der stärkste Teil dieser Messungen: beide Bibliotheken lieferten dieselbe SHA-256 über die ganze Platte und über alle 800 Bereiche, und zwei qcow2-Ausgaben waren mit qemu-img compare identisch.

Stand der Prüfung

Geprüft hat sich das Projekt selbst, und diese Prüfung ist veröffentlicht. docs/SECURITY-REVIEW-0.7.4.md vom 30.10.2026 zählt vier Low-Finding, kein High und kein Medium, alle vier offen und für 0.7.5 vorgeschlagen. Am greifbarsten ist das vierte: Die Abfrage allozierter Blöcke über HotAdd läuft über unverschlüsseltes NFC. Wer zwischen Proxy und Port 902 am Host den Verkehr ändern kann, ändert damit die Blockkarte, und ein Consumer, der nur allozierte Blöcke kopiert, überspringt Daten. Kein Notfallszenario, aber ein Punkt für die Risikoabschätzung einer produktiven Migration.

Ein Fremdaudit gibt es nicht. The Register hat am 03.11.2026 über erfolgreiche Produktivmeldungen berichtet, darunter einen deutschen Cloud-Provider und eine US-Firma, die auf Apache CloudStack und KVM umgezogen ist, und ausdrücklich dazugeschrieben, dass diese Meldungen nicht unabhängig auditiert sind. Zwölf Tage nach Veröffentlichung des Quellcodes trägt das Repository 13 Commits, zwei Contributors und 58 Stars. Der Busfaktor ist eins.

Als Vorgänger existiert cloudbase/OpenVixDiskLib mit 24 Stars, zuletzt am 08.10.2026 geändert: eine Python-Bibliothek für den NFC-Pfad, die auch schreibt, dafür vCenter 8 voraussetzt, vSphere 9 nicht getestet hat und keine Changed-Block-Abfragen kennt. OpenVDDK führt sie in seiner Clean-Room-Doku als genutzte Quelle. Freie Implementierungen dieser Bibliothek gibt es länger, neu ist die Form als austauschbare C-Bibliothek.

Was das für Kundenprojekte heißt

In unserer Host-Inventur steht kein ESXi-System und kein Backup-Pfad, der an VDDK hängt; unser Bestand läuft auf Proxmox. Relevance hat das Thema auf der Kundenseite: Wer VMware verlässt, braucht genau diesen Lesezugriff auf die Quelldaten.

Wir nehmen OpenVDDK deshalb noch nicht in den Werkzeugkasten und prüfen drei Bedingungen nach. Die erste ist Release 0.7.5 mit dem Fix aus Issue 1, bestätigt gegen eine echte 7.0-GA-Node. Die zweite ist ein eigener Lauf in einer Kunden-Umgebung, deren vSphere-Stand und Zielplattform bekannt sind, mit Datenvergleich über die ganze Kette und bis in die gestartete Ziel-VM. Die dritte ist eine schriftliche Bewertung der Clean-Room-Lage vor jedem beauftragten Einsatz, denn die Rohbeweise des Verfahrens liegen außerhalb des Repositorys.

Wer heute umzieht, hat auch ohne OpenVDDK Wege. Nutanix hat sein Migrationswerkzeug Move ohne VDDK umgebaut, OpenNebula hat die Aufnahme von OpenVDDK in OneSwap für Version 7.6 angenommen, und Red Hat dokumentiert für sein Migration Toolkit einen Behelf. Welcher Weg passt, hängt an der Ausgangsversion und am Ziel.

Die Umzugsrechnung über mehrere Jahre haben wir für drei Hosts schon einmal durchgerechnet, hier. Die einzelnen Schritte eines Umzugs stehen im Beitrag VMware zu Proxmox, und nach welchem Gate wir ein Open-Source-Projekt prüfen, zeigt der Beitrag zur Forklift-Prüfung. Alle Beiträge zu Hypervisoren, Clustern und Netzwerk laufen im Hub Server, Proxmox und Netzwerk zusammen. Wer seinen Fall nicht allein rechnen will, kann ihn mit uns durchgehen, unsere IT-Leistung für Infrastruktur und Betrieb.

Weiterführende Quellen

• OpenVDDK, Repository, Apache-2.0, Stand 11.11.2026
• OpenVDDK, Kompatibilitätsmatrix, getestete vSphere-Stände, Transportwege und Lücken
• OpenVDDK, Decision Record D-0027, Begründung des Read-only-Umfangs
• OpenVDDK, Issue 1, NBDSSL gegen standalone ESXi 7.0.0 GA, mit Mitschnitt und Fixzusage für 0.7.5
• OpenVDDK, Issue 3, Scheibenschreibzugriff und die Changed-Area-Funktionen von VDDK 9.0
• OpenVDDK, Sicherheitsreview 0.7.4, Eigenreview mit vier offenen Low-Finding
• OpenVDDK, Projektseite mit Messwerten, eigene Labore, kein unabhängiger Benchmark
• The Register: Architect creates open source replacement for VM migration tool, 03.11.2026
• ShapeBlue: Broadcom Removes VDDK Pages Without Explanation, 25.08.2026