Virtual Disk Development Kit 6.0.3 Release Notes

Contents

• About the Virtual Disk Development Kit
• New in this Release
• Compatibility Notices for Partners
• Recently Resolved Issues
• Known Issues and Workarounds

About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 6.0.3 released with vSphere 6.0 U3 is a bug-fix update to VDDK 6.0 and subsequent update releases. VDDK 6.0.3 supports the same operating systems for proxy backup as VDDK 6.0.

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.

The VMware policy concerning backward and forward compatibility is for VDDK to support N-2 and N+1 releases. In other words, VDDK 6.0 and all of its update releases support vSphere 5.1, 5.5, and 6.5 (except new features).

New in VDDK 6.0.x Releases

VDDK 6.0.3 contains bug fixes but no new features.

New setting to control NFC port. The VDDK 6.0.1 release provided a variable cnxParams.nfcHostPort to set the NFC data copy port when connecting to ESXi hosts. See the VDDK 6.0.1 Release Notes for details.

For a list of new features in the VDDK 6.0 release, see the VDDK 6.0 Release Notes.

Compatibility Notices for Partners

No SAN mode support for VMFS-6. VDDK 6.0 does not support back up of VMs residing on VMFS-6 datastores using SAN transport mode. VDDK 6.5 and higher can back up VMs residing on VMFS-6 datastores using SAN transport.

Open SSL contains backported AES-NI encryption. This release is built with Open SSL version 1.0.2 libraries, however VDDK 6.0 uses AES-NI libraries, so they were backported into Open SSL 1.0.2.

XML library upgraded.. The open source libxml2 component was upgraded from version 2.9.2 to version 2.9.4 in this release.

Statement about Virtual SAN 6.2 support. VDDK 6.0.2 was tested for functionality and interoperability with Virtual SAN 6.0. However no backup and restore testing was performed for new features in Virtual SAN 6.2, such as RAID-5 or RAID-6 erasure encoding, deduplication, and compression.

Only VDDK 5.5.4 is forward compatible with vSphere 6.0. As of the vSphere 6.0 release, only TLS connections are allowed. Connections from VDDK clients using SSLv3 are refused with an “SSL exception” error. Although partners can tell customers how to enable SSLv3 for vmacore, VMware strongly recommends upgrading backup clients to VDDK 5.5.4, which uses TLS.

For other compatibility notices from the VDDK 6.0 release, see the VDDK 6.0 Release Notes.

Recently Resolved Issues

The VDDK 6.0.3 release resolves the following issues.

• VixDiskLib sometimes crashed with a core dump in HotAdd manager loop.

  When performing a backup using HotAdd transport mode, VixDiskLib could crash and produce a core dump. The backtrace included “VcbLib::HotAdd::HotAddMgr::ManagerLoop() from ... /lib64/libdiskLibPlugin.so” followed by libvmacore.so addresses. This crash occured when the connection was marked NULL prematurely before ManagerLoop() exit. This issue has been fixed in this release.

• Intermittent HotAdd failure with LSI Logic controller.

  Though LSI Logic Parallel SCSI disks are properly mounted on the HotAdd proxy, HotAdd transport mode fails intermittently and falls back to NBDSSL, leaving disks still mounted on the proxy, and causing subsequent backup failures. This has been fixed by referencing the disk UUID instead of the controller number.

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

• Hang during volume unmount when using the Windows vstor2 driver.

  When the VixMntapi_Dismount function is called on a Vstor volume, and there is another mounted Vstor volume with high writing activity, the dismount function gets stuck in the lock volume I/O control call. This issue is encountered more frequently in Windows Server 2012 than before. The solution was to disable NTFS write caching on Vstor volumes, by presenting them as hot-pluggable devices. In this release, VixMntapi calls a new function to enable vstor2 Hotplug.

• VixMntapi_OpenDisk tried advanced transport even with NBD connection.

  On some Linux virtual machines, after VixDiskLib_ConnectEx requested NBD, the VixMntapi_OpenDisk call attempted to use advanced transports instead. This issue has been fixed in this update and in the VDDK 6.5 release. Now the specified NBD connection is used by VixMntapi_OpenDisk.

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

  Using HotAdd transport mode to backup or restore multiple disks in parallel on a target VM 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, because close initiates “ReleaseDevice” on one HotAdded disk, thereby causing read or write failure on the other(s). This issue has been fixed in this release, and in the first 6.5 update.

• VDDK 6.0 generated unnecessary log files at temporary location.

  The VDDK logging subsystem places many log messages in /tmp/vmware-root or the Temp folder. These are redundant and will be created even if custom logging functions are hooked in. This issue has been 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.

Known Issues and Workarounds

For VDDK issues found in the vSphere 6.0, 6.0 U1, and 6.0 U2 releases, see the VDDK 6.0 Release Notes, the VDDK 6.0.1 Release Notes, and the VDDK 6.0.2 Release Notes.

• Incremental backups might lose data for CBT calls during snapshot consolidation.

  When consolidating a snapshot, changed block tracking (CBT) information gets lost on its way to VixDiskLib, so any sectors changed during snapshot consolidation do not get saved by VADP based incremental backups. This is an ESXi 6.0 regression. It could cause data loss upon recovery. To avoid this issue, upgrade to ESXi 6.0 U2 or higher. See also KB 2136854.