Virtual Disk Development Kit 6.0.2 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.2 released with vSphere 6.0 U2 is a bug-fix update to VDDK 6.0 and VDDK 6.0.1. VDDK 6.0.2 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.2 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

Statement about Virtual SAN 6.2 support. VDDK 6.0.2 has been 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.2 release resolves the following issues.

• Backup and restore using SAN transport fails with VDDK 6.0.1 for VMs residing on ESXi 5.5 or earlier.

  When VDDK 6.0.1 connected to an ESXi 5.5.x host using SAN transport, and tried to retrieve the virtual machine MoRef from the snapshot managed object, the operation failed with the vmodl.fault.InvalidRequest error. This backward compatibility failure was due to changes in the getVM method between vSphere 5.5, 6.0, and 6.0.1. This issue has been fixed in this release.

• When many VMs are backed up concurrently, VDDK can crash occasionally.

  When many virtual machines are backed up in parallel, VixDiskLib might crash. The issue is not consistently reproducible, but was determined to be a problem with null entries in libgvmomi. This issue has been fixed in this release.

• Backup or restore using HotAdd transport leaves behind target VM disks on proxy.

  Backup or restore using HotAdd mode leaves behind the target virtual machine's disk, which has been HotAdded to the proxy, because snapshot removal fails. This later results in a need for disk consolidation after the snapshot is removed. However VixDiskLib_Cleanup fails when recursing through the entire disk hierarchy. This issue has been fixed in this release.

• HotAdding disks with identical names fails if they are on different adapters.

  When multiple virtual disks in a virtual machine used same slot but different adapters and different datastores, the VMDK names are identical. For example, [NewTgt] Win1/Win1.vmdk and [SAN_Tgt] Win1/Win1.vmdk look similar. When the disks were HotAdded to the proxy, stub files had the same name, one overwrite the other, and the first's backup was lost. The fix was to add the SCSI adapter number to the stub name and avoid duplication.

• Volume drive letters not returned when mounting Windows 2012 or 2008 with EFI.

  When Windows 2008 (R2) or Windows 2012 (R2) virtual machines had the EFI boot option set, the VDDK 6.0 VixMntapi_GetVolumeInfo call failed with the error message “Unrecognized Elements format expected 248 bytes, read 88” and volume drive letters were not retrieved. The fix was to correct the registry length for GPT records.

• VDDK cannot HotAdd a > 2TB disk on VVol datastores.

  When trying to open a > 2TB virtual disk for writing on VVol datastores, the following error message appeared: “Failed to hot-add SCSI targets: Vmomi::MethodFault::Exception: vim.fault.GenericVmConfigFault.” The fix is actually not in VDDK but in ESXi hosts, which should be upgraded to vSphere 6.0 U2.

Known Issues and Workarounds

For VDDK issues found in the vSphere 6.0 and 6.0 U1 releases, see the VDDK 6.0 Release Notes and the VDDK 6.0.1 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.