VDDK 5.1.1 Release Notes

vSphere 5.1 U1 release date: 25 APR 2013 | Builds: ESXi 1065491, VDDK 1042608
Last document update: 13 NOV 2014.
Check frequently for additions and updates to these release notes.


About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 5.1.1 is a bug-fix update to VDDK 5.1 released with ESXi 5.1 U1. See below for compabability notices and information about resolved issues.

For general information about this development kit, how to obtain and install the software, programming details, and redistribution, see the VDDK documentation landing page.

The following compatibility matrix shows the VMware platform products that this release was tested with (and supports):

ReleaseSupportsManaging hosts of version
VDDK 5.1.1 vCenter Server 5.1 U1ESXi 5.1 U1, ESXi 5.1, ESXi 5.0 U2, ESX/ESXi 4.1 U3, ESX/ESXi 4.0 U4
vCenter Server 5.1b ESXi 5.1 U1, ESXi 5.0 U2, ESX/ESXi 4.1 U3, ESX/ESXi 4.0 U4
vCenter Server 5.0 U2ESXi 5.0 U2, ESX/ESXi 4.1 U3, ESX/ESXi 4.0 U4
unmanaged hosts ESXi 5.1 U1, ESXi 5.0 U2, ESX/ESXi 4.1 U3, ESX/ESXi 4.0 U4

No additional guest OS testing was done for this release. VDDK 5.1.1 supports the same operating systems for proxy backup as VDDK 5.1.

VMware Consolidated Backup (VCB) has a writeup (knowledge base article) showing the support matrix for storage multipathing. VMware does not provide a similar support matrix for VDDK. Customers should seek this information from their backup software vendors.

Compatibility Notices for Partners

Switch to Microsoft runtime 9.0. The VDDK 5.1.1 libraries were compiled with Visual C++ 9.0 libraries, for compatibility with the glib called by VMware Tools. Developers must ensure that consumers of their software have installed the 9.0 runtime, version 30729.6161 or later. Earlier versions throw a SideBySide error. Here are the Visual C++ 2008 SP1 redistributable packages: for x86 and for x86-64. This change does not affect Linux libraries.

Error 87 with Windows 2012 NTFS. NTFS virtual disk from Windows Server 2012 might produce “Error 87” when a backup proxy mounts the disk read-only on earlier versions of Windows Server. The VDDK log contains the error “Volume/NTFS filesystem is corrupt (87).” If you encounter this issue, one workaround is to mount these virtual disks read/write so that the system has a chance to repair them.

For older compatibility notices from the VDDK 5.1 release, see the VDDK 5.1 Release Notes.

Recently Resolved Issues

The VDDK 5.1.1 release resolves the following issues:

  • Disk Open works without an SSL thumbprint from vCenter.

    Whenever vCenter Server did not provide an SSL thumbprint for the target host, the VDDK library could core dump in the function VixDiskLib_Open(). This occurred (but not always, depending on memory content) when vCenter Server 5.1 was managing virtual disk on ESXi 5.0 and older hosts. The problem is fixed in this release.

  • VDDK package is 5.1.1 for vSphere 5.1 U1 release.

    In this release, the installable packages are named VMware-vix-disklib-5.1.1-buildnumber.

  • Same glib version for VDDK and VMware Tools.

    The VDDK libraries for Windows are now built with Visual C++ version 9 to match the VMware Tools build environment, avoiding glib discrepancies that sometimes caused intermittent core dumps seemingly from VDDK code. See Compatability Notices above.

  • SLES 10 SP2 requires newer OpenSSL library.

    In this release, OpenSSL is updated from version libssl.so.0.9.8t to version libssl.so.0.9.8x so VDDK works correctly with SLES 10, SLES 10 SP1, and SLEs 10 SP2.

  • No segmentation violation during library disconnect.

    When many Linux processes ran simultaneously, some of them crashed with SIGSEGV when calling VixDiskLib_Disconnect() before exit. This sometimes occurred on Windows too. The problem is fixed in this release.

  • Changed Block Tracking could return full thin-provisioned disk.

    On VMFS file systems holding very large thin-provisioned disk (> 200GB) calls to QueryChangedDiskAreas formerly returned incorrect results if the number of ioctl calls for query exceeded a fixed limit. This caused QueryChangedDiskAreas to return all areas (the full disk) rather than only the in-use areas of thin-provisioned disk. This resulted in longer backup time and excessively large backup data. It was especially noticeable on Linux ext2 and ext3 file systems. This issue is resolved in this release.

  • HotAdd open fails when volume spans multiple disks.

    When a Windows HotAdd proxy was configured with a volume that spans multiple disks, VixDiskLib_Open() failed to open the HotAdded virtual disk of the target virtual machine. The problem is fixed in this release.

  • Hang in connect or cleanup due to intermittent race condition.

    Windows processes could sometimes hang while calling VixDiskLib_ConnectEx() or VixDiskLib_Cleanup() due to a race condition while loading or unloading libraries. This has been fixed in this release.

  • VMware Tools no longer installs earlier version of Visual C++ runtime.

    For use with VDDK, VMware Tools sometimes installed an older version of Microsoft's Visual C++ runtime library on the backup proxy, even if a newer version was already installed. For example, VMware Tools installed runtime version 9.0.30729.4148 even when version 9.0.30729.6161 existed on the proxy virtual machine. This issue is resolved in this release. If a newer version of the Microsoft Visual C++ runtime library is available on a virtual machine, VMware Tools does not install an old version.

Known Issues and Workarounds

The following VDDK issues were reported after the October 2012 vSphere 5.1 refresh. In most cases a fix has been identified, but not integrated and tested.

  • Open call might crash after network login with NBD transport.

    It is possible for the VixDiskLib_Open call to crash in gvmomi.dll after an NFC (network file copy) login, required for NBD mode, has failed. The gvmomi library initially checks for an empty load queue, but then references the queue without rechecking. VixDiskLib_PrepareForAccess and VixDiskLib_EndAccess can also cause a crash when the load queue is empty. A fix has been identified and will be available in a future release.

  • Threads still running after VixDiskLib_Exit call.

    When the VDDK plugin is loaded, several threads are started that cannot be shut down until the calling application exits. For instance on Windows Server 2008, VDDK libraries may leave threads running after the VixDiskLib_Exit call. Still-running threads are from the vCenter vmacore library and cannot be unloaded until the application finishes. The leftover threads should be harmless, except if the backup proxy runs as a VM on ESXi 5.1, the calling application can terminate unexpectedly.

  • HotAdd forward compatibility fails with error 13.

    When VDDK 5.1 or 5.1.1 programs access virtual disk on ESXi 5.5 hosts using HotAdd, VixDiskLib_Open fails when retrieving metadata before disk gets HotAdded. The message is “Error 13 - You do not have access rights to this file.” A library fix has been identified and will appear in the next VDDK 5.1 update release.

  • Snapshot delta files not consolidated after backup.

    In NBD mode, or after SAN backup, log messages appear for *-delta.vmdk files saying “Device or resource busy” and snapshot consolidation fails with “The file is already in use” error. In this scenario where the connection has been closed on the disk due to idle time, any attempt to read or write on the disk will not succeed. This issue has two possible causes. The first applies only to SAN transport mode on physical proxies, and occurs when consolidation is attempted before releasing the backup proxy lease. See KB 2040846 for a workaround. The second cause is an NFC network timeout while using NBD mode or after SAN mode falls back to NBD. See KB 2050453 for details. VDDK 5.5 fixes both issues.

  • Sporadic application exit during SAN restore.

    An issue has been discovered in VDDK where a stack overflow can occur on a physical proxy if any of its disks have 29 or more partitions. This will result in the backup application exiting unexpectedly or crashing. The only known workaround is to ensure that the physical proxy does not have a disk with more than about 25 partitions. This issue applies only to SAN transport mode on physical proxies.

  • Backing up the HotAdd proxy causes left-over virtual disk.

    HotAdding virtual disk to back up the proxy itself results in unremovable disk. While the proxy is running, ESXi hosts do not allow removal of HotAdd disk, even using the vSphere (Web) Client. The workaround is to avoid running HotAdd back up on the proxy virtual machine. To recover from left-over HotAdd disk, first power off the proxy, then use the vSphere (Web) Client to remove the disk from the proxy, but do not erase this disk,

  • Boot disk should be scsi0:0 for use with mount API.

    When a virtual machine's boot disk is not on scsi0:0, the VixMntApi_GetVolumeInfo function does not correctly return the inGuestMountPoints (such as drive letter C:) or the numGuestMountPoints. On a scsi0:0 disk the correct information is returned, but not otherwise. For example with a scsi0:2 boot disk, the two properties are not populated. This issue has been reported against VDDK 5.0 and later.

For VDDK issues that were identified during the vSphere 5.1 release or in the previous vSphere 5.0 release, see the VDDK 5.1 Release Notes.