VMware

VDDK 5.1.4 Release Notes

Release date: 4 DEC 2014 | Builds: ESXi 2323236, VDDK 2248791.
For vSphere 5.1 U3. Last document update: 7 JAN 2015.
Check frequently for additions and updates to these release notes.

Contents



About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 5.1.4 for ESXi 5.1 U3 is a bug-fix update to VDDK 5.1.2 and 5.1.3, which was a security update. 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.

For a compatibility table of vSphere releases and VDDK versions, see the VDDK 5.1.2 Release Notes.

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

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 or U3. VDDK 5.1 U2 or U3 are required for HotAdd transport mode to be used against vSphere 5.5.

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

  • End Access call crashes if hostname does 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 hostname. This has been fixed in this release.

  • 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.1 U3 fixes this issue by removing the need for the VDDK user to have Global.Licenses privilege at Datacenter level. See KB 2008157 for other privileges that are required.

  • 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.1 U3 fixes this issue by failing over to NBDSSL in this case.

  • VDDK version number incremented.

    The VDDK version number is 5.1.4 for vSphere 5.1 U3. (VDDK 5.1.3 was a security only release.) Development partners should note that the Open Source License list has changed.

  • Assert failure caused exit when HotAdd cannot acquire lock.

    When a backup using HotAdd transport could not acquire a file lock, and later tried to release the non-existent lock, it logged the error message “Panic: Assert Failed: _lockToken != __null” and exited prematurely. Possibly VIX_E_FILE_ERROR also appeared. This was fixed by using method HotAddMgr::NotifyAll to trigger retry of original HotAdd backup in a different transport mode.

  • HotAdd backup fails if SCSI target is already in use.

    With parallel backups using HotAdd mode, the Reconfigure operation could fail when the proxy adds the backed-up virtual disk, because a particular SCSI target may already be occupied by another backup run by a parallel thread or process. Failure to catch and throw an exception in HotAddMgr::Reconfigure resulted in failure of backup. The fix was to catch and rethrow the exception in HotAddMgr::ProcessItems, so the ScsiHotAddImpl thread gets notified about HotAdd failure status.

  • 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.

VDDK 5.1.3 resolved the following issue, as does VDDK 5.1.4:

  • OpenSSL library updated.

    In this VDDK release, the OpenSSL library was updated to version openssl-0.9.8za to address CVE-2014-0076, CVE-2014-0224, and CVE-2014-3470. There are no other changes from the previous VDDK update release.

For issues that were resolved by the VDDK 5.1.1 and 5.1.2 releases, see the VDDK 5.1.1 Release Notes and VDDK 5.1.2 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.

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