OpenVDDK 0.7.4 für VMware-⁠Festplatten – Ersatz für definierte Lesezugriffe

Wer VMware-⁠Festplatten mit Drittanbieterwerkzeugen auslesen will, kann dafür eine Open-Source-Implementierung der VixDiskLib-⁠Schnittstelle einsetzen. OpenVDDK 0.7.4 ist jedoch ausdrücklich auf unterstützte, schreibgeschützte Linux-⁠Workflows begrenzt. Für Migrationsteams ist das ein möglicher Baustein, aber kein vollständiger Ersatz für alle Funktionen des VMware VDDK.

OpenVDDK setzt an der Bibliothek für den Festplattenzugriff an

Das VMware Virtual Disk Development Kit stellt eine Bibliothek bereit, über die Drittanbieterprogramme virtuelle VMware-⁠Festplatten außerhalb des Hypervisors lesen können. Nachdem Broadcom im September 2026 den öffentlichen Zugriff auf die Download-⁠Seite des VDDK gesperrt hat, bleibt eine bereits heruntergeladene Kopie weiter nutzbar. Wer eine neue benötigt, muss dagegen einen anderen Weg finden.

OpenVDDK setzt nicht bei der virtuellen Festplatte selbst an, sondern bei der Schnittstelle, die Werkzeuge für den Zugriff verwenden. Der Entwickler Andrija Panić hat die VixDiskLib-⁠Schnittstelle in Version 8.0.3 eigenständig für Linux x86-⁠64 implementiert. Bei unterstützten schreibgeschützten Anwendungen kann die OpenVDDK-⁠Bibliothek laut Entwickler die erwartete VMware-⁠Bibliothek ersetzen. Die Anwendung muss dafür nicht geändert oder neu kompiliert werden; anschließend werden die Prozesse neu gestartet, die die Bibliothek verwenden.

Das kann besonders dann nützlich sein, wenn ein bestehender Migrationsablauf auf die Schnittstelle angewiesen ist. Die Installationsanleitung beschreibt außerdem, wie nbdkit und virt-⁠v2v auf ein separates OpenVDDK-⁠Kit verwiesen werden können. Bibliotheksnamen, SONAME und Symbolversionen stimmen laut Projektbeschreibung mit der erwarteten Schnittstelle überein.

Die Kompatibilität ist auf konkrete Umgebungen begrenzt

Die angegebene Kompatibilitätsliste für Version 0.7.4 umfasst vSphere 6.7, 7.0 und 8.0. Als getestete Stände nennt der Entwickler 6.7 U3, 7.0.3 und 8.0.3. Verbindungen sind über vCenter oder direkt zu ESXi möglich, auch zu eigenständigen Hosts. Bei den Transportwegen werden HotAdd über vCenter sowie NBDSSL und NBD aufgeführt. Unterstützt wird Linux x86-⁠64 mit glibc 2.28 oder neuer.

Zusätzlich berichtet der Entwickler von erfolgreichen Tests mit vSphere 9.1.1 und VMware 9.1, darunter auch mit verschlüsselten virtuellen Maschinen. Diese Angaben ergänzen die aufgeführte Kompatibilitätsliste, ersetzen aber nicht die Prüfung der eigenen Kombination aus vSphere-⁠Version, Transportweg und eingesetztem Werkzeug. Eine pauschale Aussage, OpenVDDK funktioniere mit jeder VMware-⁠Umgebung oder jedem Migrationsprogramm, lässt sich daraus nicht ableiten.

Schreibzugriffe gehören ausdrücklich nicht zum Einsatzbereich

OpenVDDK ist laut Entwickler standardmäßig schreibgeschützt. Schreib-⁠ und Wiederherstellungsvorgänge auf Festplatten sowie Zugriffe auf SAN-⁠ und lokale Dateien werden nicht unterstützt. Auch die Zahl der exportierten Funktionen sollte nicht als Funktionsgarantie missverstanden werden: Zwar stellt die Implementierung alle 43 öffentlichen Funktionsexporte von VixDiskLib 8.0.3 bereit, doch die Unterstützung einzelner Operationen und bekannte Abweichungen sind gesondert dokumentiert.

Für die Praxis ist diese Grenze entscheidend. Ein Werkzeug, das virtuelle Festplatten nur lesen muss, kann grundsätzlich in den vorgesehenen Anwendungsbereich fallen. Ein Ablauf, der Änderungen an den Festplatten oder Wiederherstellungsvorgänge erwartet, lässt sich dagegen nicht allein dadurch abdecken, dass die Bibliothek dieselben Funktionsnamen exportiert. Prüfen Sie deshalb zuerst, welche konkreten Funktionen Ihr bestehender Prozess tatsächlich verwendet.

Gemeldete Einsätze sind ein Anhaltspunkt, kein Eignungsnachweis

Der Entwickler berichtet von Rückmeldungen unabhängiger Tester zu Forklift für VMware-zu-KubeVirt-Migrationen, zu Migration Toolkit for Virtualization auf OpenShift, zu einer Proxmox-⁠VE-⁠Pipeline und zu eigenen nbdkit-⁠Werkzeugen. Außerdem nennt er Rückmeldungen aus Produktivumgebungen, darunter Migrationen mit V2K Migrate. Das sind Hinweise darauf, dass OpenVDDK in unterschiedlichen Abläufen erprobt wird. Sie belegen jedoch nicht, dass jede Umgebung oder jeder Produktionsprozess damit funktioniert.

Für eine geplante Migration ist daher ein begrenzter, passender Test sinnvoll: Stimmen die eingesetzte vSphere-⁠Version und der Transportweg mit dem vorgesehenen Einsatz überein, und benötigt das Werkzeug tatsächlich nur Lesezugriff? Erst wenn die konkrete Kombination den eigenen Ablauf abdeckt, sollte OpenVDDK in dessen reguläre Planung aufgenommen werden. Ein bloßer Austausch der Bibliothek ist keine belastbare Freigabe für einen vollständigen Migrationsprozess.

Die Lizenz erlaubt Nutzung, ersetzt aber keine technische Prüfung

OpenVDDK wird unter der Apache-2.0-Lizenz veröffentlicht. Die Lizenz erlaubt Nutzung, Änderungen, Forks und Weiterverbreitung, auch in kommerziellen Produkten, unter Beachtung ihrer Bedingungen und Hinweispflichten. Das macht die Bibliothek für Unternehmen grundsätzlich zugänglich; über technische Eignung, Supportbedarf oder den Erfolg einer Migration sagt die Lizenz nichts aus.

Behandeln Sie OpenVDDK als gezielten Ersatz für unterstützte Lesezugriffe und testen Sie vor dem Einsatz, ob Ihr konkreter Migrationsweg innerhalb dieser Grenze bleibt.

Quellen: Borns IT-⁠ und Windows-⁠Blog – „OpenVDDK: Open-⁠Source-⁠Ersatz für VMware VixDiskLib“ (https://borncity.com/blog/2026/11/03/openvddk-open-source-ersatz-fuer-vmware-vixdisklib/)