VDDK 5.1.2 Release Notes

Release date: 16 JAN 2014 | Builds: ESXi 1483097, VDDK 1422937.
For vSphere 5.1 U2 GA. Last document update: 15 OCT 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.2 with ESXi 5.1 U2 is a bug-fix update to VDDK 5.1 and a follow-on to the 5.1 U1 release. See below for compatibility 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 lists the VMware platform products that the VDDK 5.1.2 release supports.

ReleaseSupportsManaging hosts of version
VDDK 5.1.2 vCenter Server 5.1 U2ESXi 5.1 U2, ESXi 5.1 U1, ESXi 5.1, ESXi 5.0 U2, ESX/ESXi 4.1 U3, ESX/ESXi 4.0 U4
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 U3ESXi 5.0 U3, 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 U2, ESXi 5.1 U1, ESXi 5.1, 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.2 supports the same operating systems for proxy backup as VDDK 5.1.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

Forward compatibility with VDDK 5.5. VDDK 5.1 HotAdd does not work on vSphere 5.5 unless you compile with VDDK 5.1 U2. VDDK 5.1 U2 is required for HotAdd transport mode to be used against vSphere 5.5.

Switch to Microsoft runtime 9.0. The VDDK 5.1.1 and 5.1.2 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.2 release resolves the following issues:

  • OpenSSL library upgraded again on Linux.

    To close a few security holes, the OpenSSL library in vSphere 5.1 U2 was upgraded from version 0.9.8x to version 0.9.8y. Then to prevent a core dump when loading diskLibPlugin, the Linux OpenSSL library was upgraded to match.

  • Threads still running after VixDiskLib_Exit call.

    When the VDDK plugin was loaded, several threads were started that could not be shut down until the calling application exited. For instance on Windows Server 2008, VDDK libraries left threads running after the VixDiskLib_Exit call. Still-running threads were from the vCenter vmacore library and could not be unloaded until the application finished. The leftover threads should be harmless, but in some cases the calling application could terminate unexpectedly. Even with the fix in this release, threads will continue to run as before. This fix addresses only the logging attempts that caused problems, not thread termination, due to extensive code changes required for termination.

  • Sporadic application exit during SAN restore. An issue was discovered where a stack overflow could occur during SAN restore on a physical proxy if any of its disks had 29 or more partitions. This resulted in the backup application exiting unexpectedly or crashing. Memory allocation algorithms were changed to prevent this issue.

  • HotAdd forward compatibility fails with error 13.

    When VDDK 5.1 or 5.1 U1 programs access HotAdded virtual disk on ESXi 5.5 hosts, VixDiskLib_Open fails when retrieving metadata before a disk gets HotAdded. The message is “Error 13 - You do not have access rights to this file.” This was fixed by changing the VDDK 5.1 U2 release to pass the OPEN_LOCK option when retrieving disk metadata before HotAdding a disk. The fix allows software compiled with VDDK 5.1 U2 to HotAdd disk on ESXi 5.5 hosts.

  • In VDDK 5.1.1 a Windows DLL lacked version information.

    In VDDK 5.1.1 the gvmomi.dll library for Windows lacked version information, so the Microsoft installer (MSI) did not recognize it as an upgrade. This caused problems for customers upgrading their vendor's VDDK redistribution. In this release all the DLL files contain version information. Gvmomi stands for Glib VM object management infrastructure.

  • Clone of virtual disk might fail during SSL thumbprint lookup.

    In VDDK 5.1 and 5.1.1, the VixDiskLib_Clone function will crash after getting the NFC ticket and looking up its SSL thumbprint, if the NFC ticket is empty. This is fixed in this release by validating the host entry in the NFC ticket before SSL thumbprint lookup.

  • Snapshot delta files not consolidated after backup.

    When specifying SAN or Auto transport mode on a physical proxy, if a disk was not accessible with SAN mode, backup proceeded by falling back to another (available) transport mode. However if the previously acquired SAN mode lease on the disk was not released, the backup proxy continued to hold the lease and the disk remained locked, preventing proper cleanup afterwards. With NBD mode, a similar scenario could occur due to NFC network timeouts. In either case, log messages appeared for *-delta.vmdk files saying “Device or resource busy” and snapshot consolidation failed. See the VDDK 5.1 U1 Release Notes for details. This release fixes both issues.

  • After Storage vMotion, incremental backups fail with FileFault error.

    In earlier releases, VM cold relocation (virtual machine powered off) caused a loss of changed block tracking (CBT) state, so incremental backups failed with the FileFault error. If source and destination datastores are accessible to both hosts, CBT state should be maintained after cold relocation of VMs. This is similar to fixed issue “Storage vMotion and changed block tracking” in VDDK 5.5.

For issues that were resolved by the VDDK 5.1.1 release, see the VDDK 5.1.1 Release Notes.

Known Issues and Workarounds

The following VDDK issues were reported after the October 2012 vSphere 5.1 refresh.

  • Virtual machine restore may crash during socket operations.

    During virtual machine restore, crashes have been reported due to an unexpected exception thrown by the vmacore library calling the async_connect function. This could be caused by network conditions such as loopback being rejected by a firewall. A fix has been identified and will be available in a future release.

  • 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. A fix has been identified and will be available in a future release.

  • End Access call crashes if hostname does not resolve.

    Calls to VixDiskLib_EndAccess crash at VixDiskLibVim_AllowVMotion+0x169 if the server name provided in connection parameters (cnxParams.serverName) does not resolve correctly as a valid hostname. A fix has been identified and will be available in a future release.

  • Assert failure causes exit when HotAdd cannot acquire lock.

    When a backup using HotAdd transport cannot acquire a file lock, and later tries to release the non-existent lock, it logs the error message “Panic: Assert Failed: _lockToken != __null” and exits prematurely. VIX_E_FILE_ERROR might appear also. A fix has been identified and will be available in a future release.

  • 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 and vSphere 5.0 releases, see the VDDK 5.1 Release Notes.