VDDK 5.5.5 Release Notes

Release date: 16 SEP 2015 | Build: ESXi 3029944, VDDK 2962804.
For ESXi 5.5 U3. Last document update: 9 MAR 2016
Check frequently for additions and updates to these release notes.

Contents



About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 5.5.5 released with vSphere 5.5 U3 is a bug-fix update to VDDK 5.5 and subsequent 5.5.x releases.

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 and install the software, programming details, and redistribution, see the VDDK documentation landing page.

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

Compatibility Notices for Partners

Customers looking for Transport Layer Security version 1 (TLSv1) support should update their existing VDDK libraries using this release. Because vSphere 5.5 U3b now requires TLS instead of SSLv3, backup software must be compiled against VDDK 5.5.4 or 5.5.5 for compatibility, unless customers reenable SSLv3 (see KB 2139396).

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

Recently Resolved Issues

This VDDK 5.5.5 release resolves the following issues:

  • Error returned when ESXi host reaches NFC memory limit.

    Previously, VDDK would hang during I/O operations if the host ran out of NFC memory. This has been fixed in this release. You must upgrade both VDDK and ESXi to get the fix. VDDK now returns the VIX_E_OUT_OF_MEMORY error, leaving the disk handle in a still-valid state. Upon receiving this error, the caller can try again with a smaller I/O buffer, retry at a later time, perform other operations on the disk, or close the disk.

  • Backups fail when a non-default port is specified for vCenter Server.

    By default VDDK uses port 443 to establish connections with vCenter Server. If customers set a different port, then backup and restore will fail, and the following error message can be observed in the VDDK log file: “No address returned. Could not resolve server name for IP/DNS name: Port (Error 14008)” This was fixed by taking the non-default port specified in connectionParams.

  • Avoiding application crash when retrieving ServiceInstance content.

    Backup vendors reported crashes when their applications attempted to retrieve ServiceInstance content from vCenter Server. The cause was apparently the failure to acquire a lock on the connection. This release creates a connection lock, which resolves the problem.

  • VDDK users required Global.Licenses privilege for backup and restore.

    Starting with VDDK 5.1, the Global.Licenses privilege at Datacenter level was required for VDDK users to initiate backup and restore procedures. However this made it impossible for VDDK users without this privilege to initiate backup or restore from vCenter Server. ESXi 5.5 U3 fixes this issue by removing the need for the VDDK user to have Global.Licenses privilege at Datacenter level; Global.EnableMethods is sufficient. See KB 2008157 for other privileges that are required.

  • On a Linux proxy using SAN transport, backup and restore fail intermittently.

    With SAN transport mode, backup and restore fail intermittently when run from a Linux proxy. The failure occurs in the jdiskLib.Read() method, and two error messages appear: “One of the parameters supplied is invalid” and “No active paths found.” This has been fixed by retrying read/write not only after EBUSY, but also after EIO from SCSI reservation conflicts.

  • HotAdd transport mode works again on stand-alone ESXi host.

    After vSphere 5.1 is upgraded to vSphere 5.5, HotAdd transport mode stops working with ESXi 5.5 hosts not managed by vCenter Server, because of additional security checks added in the release. At reconfigure time, ESXi 5.5 throws the HostAccessRestrictedToManagementServer fault. Some customers need HotAdd for backing up unmanaged ESXi hosts. The fix in ESXi 5.5 U3 is to set not only the Shares property but also storageIOAllocation, so HotAdd transport mode works again with stand-alone ESXi hosts.

  • Cleanup function did not validate thumbprint with SSL certificates enabled.

    When SSL certificate checking is enabled, the VixDiskLib_Cleanup() function fails to validate the thumbprint, resulting in a failure to clean up after a restore. The messages “Error occurred during cleanup operation” and “Unable to connect to the host” appear in log files. For this release, the cleanup funciton was modified to validate the thumbprint when SSL certificate verification is enabled.

  • End Access call crashed if hostname did not resolve.

    Calls to VixDiskLib_EndAccess crashed at VixDiskLibVim_AllowVMotion+0x169 if the server name provided in connection parameters (cnxParams.serverName) did not resolve correctly as a valid DNS hostname. This has been fixed in this release.

  • VDDK core file after double free or corruption error.

    When backing up virtual machines using SAN transport mode, occasional program crashes resulted in a core file, with log files showing that glibc had detected the “double free or corruption” error. This issue could be reproduced by passing NULL as the connection user or password. The fix was to reinitialize various connection parameters as necessary.

  • During restore, SAN transport is autoselected but unavailable.

    When trying to restore a virtual machine from backup data, VDDK libraries might select SAN transport even though it is not available to the data mover. This occurs primarily when the data mover is a physical machine. ESXi 5.5 U3 fixes this issue by failing over to NBDSSL in this case.

  • Assert failure when getting NFC ticket during multiple VM backups.

    Before opening a virtual disk, the VMware libraries log into vCenter Server and acquire an NFC ticket. When multiple backup applications run on one host, or when one backup application simultanously backs up multiple virtual machines, the VMware libraries apparently have timer-related issues. An assertion failure when getting an NFC ticket causes the application to crash. The fix was to insert a negligible timeout before getting the NFC ticket.

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

    It was possible for the VixDiskLib_Open call to crash in gvmomi.dll after an NFC (network file copy) login, required for NBD mode, failed. The gvmomi library initially checked for an empty load queue, but then referenced the queue without rechecking. VixDiskLib_PrepareForAccess and VixDiskLib_EndAccess could also cause a crash when the load queue is empty. These issues are fixed in this release.

The VDDK 5.5.4 release resolved the following issue:

  • Enable support for TLSv1 with VDDK 5.5.

    Using VDDK 5.5.x advanced transport modes for backup and restore against vSphere 6.0 does not work, because VDDK requests SSLv3, which is disabled by default to address CVE-2014-3566, commonly referred to as the POODLE attack. This issue is also resolved in the VDDK 5.5.5 release by enabling support for and requesting Transport Layer Security version 1 (TLSv1).

For issues resolved in the VDDK 5.5.3 release, see the VDDK 5.5.3 Release Notes.

Known Issues and Workarounds

This issue was discovered in both VDDK 5.5.5 and VDDK 6.0.

  • Error not returned when ESXi host reaches NFC connection limit.

    This issue causes an apparent hang in backup, or slowness of vCenter Server. The VIX_E_OUT_OF_MEMORY error is returned in cases when an ESXi host reaches the NFC memory limit (see fixed issue above), but not for other NFC limits such as the number of connections. As a workaround programs can check that the “Number of current connections” is less than the VMware recommended NFC session connection limit before making another VixDiskLib_Open(Ex) call. See section NFC Session Limits in the Virtual Disk Programming Guide. ESXi host limits depend on consumed buffer space (32MB) not just the number of connections. VixDiskLib_Open(Ex) uses one connection for every virtual disk accessed on an ESXi host. It is not possible to share a connection across virtual disks. Connections made through vCenter Server are limited to a maxiumum of 52, then the ESXi host limits listed above apply.

For issues in the VDDK 5.5.3 release, see the VDDK 5.5.3 Release Notes.

For issues that were identified in the VDDK 5.5 release, see the VDDK 5.5 Release Notes.