Virtual Disk Development Kit Release Notes

Release date: 27 JUL 2017 | Builds: ESXi 5969303, VDDK 5993564
VDDK 6.5.1 for vSphere 6.5 U1 | Last document update: 12 MAR 2018
Check frequently for additions and updates to these release notes.


About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 6.5.1 is a bug-fix release to support vSphere 6.5 U1.

VDDK is used with vSphere Storage APIs for Data Protection (VADP) to develop backup and restore software. For general information about this development kit, how to obtain the software, programming details, and redistribution, see the VDDK documentation landing page.

VDDK 6.5 was tested with the following operating systems to perform proxy backup:

  • Windows Server 2012 and 2012 R2
  • Windows Server 2008 R2
  • Windows 10
  • Red Hat Enterprise Linux RHEL 6.7, 6.8, and 7.2
  • SUSE Linux Enterprise Server SLES 11 SP4 and 12 SP1.

VDDK 6.5.1 was tested with these additional systems to perform proxy backup:

  • Red Hat Enterprise Linux RHEL 7.3
  • Windows Server 2016.

Changes and New Features

This release contains bug fixes but no new features.

Compatibility Notices

This VDDK release is forward compatible with vSAN 6.6 and vSAN 6.6.1.

ESXi hosts and especially vCenter Server should be upgraded in conjunction with VDDK libraries.

Recently Resolved Issues

The VDDK 6.5 U1 release resolves the following issues.

  • Two DLL files have wrong manifest, requiring install of redistributable.

    The Windows ZIP file for VDDK 6.5 contains gobject-2.0.dll and libeay32.dll with incorrect manifests, making them depend on two Visual C++ 9.0 versions, both 9.0.32709.4148 and 9.0.21022.8. This caused a failure to load vixDiskLibVim.dll with error code = 0x36b1, which means side-by-side configuration is incorrect. In this release, glib and opelsssl were fixed to depend on version 9.0.32709.4148 only.

  • Dependency on the LZMA library removed.

    VDDK 6.5.0b modified the XML shared library to depend on the compression library liblzma, which is missing from some Linux distributions. This caused runtime failure of libvixDiskLibVim. In this release, the unnecessary dependency has been removed.

  • HotAdd mode backup crashes due to unavailable status disks.

    When the HotAdd backup proxy contains status disks from a previous backup that are missing in the currently backed-up VM, null pointers are encountered and the backup program crashes. The workaround is to remove missing disks from the backup proxy beforehand. This issue has been fixed in this release by ignoring disks with unavailable status when VDDK is discovering the HotAdded disks.

  • Version numbers missing for EXE file and two DLLs in package.

    The major and minor version numbers were set to 0.0 for diskLibPlugin.dll, vixDiskLib.dll, and vmware-vdiskmanager.exe causing the MSI upgrade installer to fail. This was regression in VDDK 6.5, fixed in this update.

  • NBD transport was quietly switched to slower NBDSSL mode.

    The VDDK 6.5 release forced NBD transport mode to use SSL encryption, making it in effect NBDSSL mode. Customers and partners complained that this caused slower performance. This release contains a fix to allow continued use of unencrypted NBD, except for encrypted VMs, which are switched to NBDSSL.

  • VDDK 6.5 had XML library 2.9.2 instead of more secure 2.9.4 version.

    Partners noticed that although the VDDK 6.5 open sources licenses file listed libxml2 version 2.9.4, the development kit actually contained version 2.9.2, which has known security vulnerabilities. This packaging error is fixed in this release.

  • Mounting System or BCD registry hives caused Windows error 32.

    After mounting volumes with VixMntapi_MountVolume, the System or boot configuration data (BCD) registry hive was locked to prevent access. Attempting to mount other volumes caused Windows error 32. This issue was found in VDDK 6.0 and fixed in this release.

  • VDDK crashes after disk open call and session login attempt.

    When trying to retrieve the NFC ticket for a disk after VixDiskLib_OpenEx, VDDK crashes intermittently (due to a null pointer read in gvmomi) when it attempts a session login to vCenter Server. This issue, similar to the one below, is fixed in this release.

  • VDDK crashes after disk open call after running for some time.

    When trying to load transport modules after calling VixDiskLib_Open, VDDK crashes every few days due to a null pointer error in gvmomi. This issue, similar to the one above, is fixed in this release.

  • VixMntapi_OpenDisks() on Linux results in defunct processes.

    After calling VixMntapi_OpenDisks on Linux, the main parent process does not wait for a child process to exit, so a zombie process results. The fix is for to wait for exit(2) from the main process.

  • SAN mode access to vSAN or VVol datastore hangs ESXi host.

    VVol and vSAN datastores do not support SAN mode transport. If a program calls VixDiskLib_ConnectEx on a VVol or vSAN datastore, specifying SAN mode or nothing (auto-detected SAN mode), the ESXi host stops responding and the VDDK connection fails. In this release, the fix is to refuse SAN transport for VVol and vSAN.

  • Disk clone is not supported for vCenter Server.

    The VixDiskLib_Clone function can be used to transfer hosted disk from VMware Workstation to managed disk on an ESXi host. In previous releases, it could be run on ESXi hosts, but not on vCenter Server. In this release, VixDiskLib_Clone can be run on vCenter Servers.

  • When HotAdding disk on VVol datastore with CBT enabled, guest OS is unresponsive.

    On a VVol datastore, when the backup proxy HotAdds virtual disk for a VM that has Change Block Tracking (CBT) enabled, the guest OS becomes unresponsive until HotAdd completes. The VM is stunned and waiting for CBT initialization, delayed by many unsharedChunksVirtualVolume calls to the VASA Provider. This behavior has been optimized in this release so the guest OS remains responsive.

  • HotAdd failure when multiple target VM disks are opened and closed in parallel.

    When using HotAdd transport mode to backup or restore multiple disks on a target VM in parallel could result in read or write failures. This failure occurs when VixDiskLib_Close is called for one of the disks while reads or writes are still occurring on another disk. This is because VixDiskLib_Close initiates “ReleaseDevice” on one HotAdded disk of the VM, thereby resulting in read or write failure on the other(s). Also fixed in VDDK 6.0.3.

  • VixDiskLib process wedged while trying to restore large virtual disk.

    Customers reported a spinning process when restoring a 5TB virtual machine. Stack traces indicated that resource contention caused a deadlock. After analysis, code was rewritten to make it multithread safe. This update release includes that fix.

Known Issues and Workarounds

The VDDK 6.5.1 release has the following known issues:

  • HotAdd proxy failure with Windows Server backups

    If there is SATA controller in the Windows backup proxy, HotAdd mode might not work. The cause is that VDDK does not rescan SATA controllers after HotAdding, so if there exist multiple SATA controllers or ACHI controllers, VDDK might use the wrong controller ID and fail to find the HotAdded disk. Disk open fails, resulting in “HotAdd ManagerLoop caught an exception” and “Error 13 (You do not have access rights to this file)” errors. The workaround in this case is to remove the SATA controller from the Windows backup proxy. A fix has been found and will be provided in a future release. See KB 2151091.

  • VDDK may crash during PrepareForAccess.

    VDDK could crash when calling VixDiskLib_PrepareForAccess with the “vmodl_vim_fault_method_already_disabled” error. This was a regression because the NULL fault was not considered. A fix has been found and appeared in VDDK 6.5.2 and later.

  • Log file entries related to blacklist are missing in VDDK 6.5.

    Log file entries (at the verbose and trivial levels) related to device blacklisting are missing in VDDK 6.5 and 6.5.1 as compared to VDDK 6.0. A fix will appear in a future release.

  • Virtual disks must be offline for HotAdd restore.

    The Virtual Disk Programming Guide used to recommend SAN policy OnlineAll for Windows 2008 and later. This recommendation was removed for the VDDK 6.5.1 release. Disk online may cause signature collision problems and restore problems. For HotAdd transport, VMware suggests customers running Windows 2008 R2 or later set SAN policy to OfflineShared or OfflineAll.

For more issues in the VDDK 6.5 release, see the VDDK 6.5 Release Notes.