VDDK 7.0.3.3 | 20 June 2023 | ESXi build 7.0 U3 + patches, VDDK build 21933544 For VMware Cloud Disaster Recovery (VCDR) | Last document update 6 November 2023 Check back for additions and updates to these release notes.

About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 7.0.3.3 is a feature update to permit retry of network connections and resolve some reported issues.

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 the software, programming details, and redistribution, see the VDDK landing page on developer.vmware.com.

Changes and New Features

VDDK 7.0.3.3 offers the following features:

• New: Rather than return Error 13 “cannot open file” or “file read failed” after network connection errors, VixDiskLib_Open now returns an actual network error, such as VIX_E_HOST_NETWORK_CONN_REFUSED for network dysfunction or VIX_E_HOST_SERVER_SHUTDOWN for machine powered off.
• Note that VDDK 7.0.3.2 supported five additional operating systems as backup proxy VMs for HotAdd and other transports: Red Hat Enterprise Linux (RHEL) 7.9, 8.6, 9.0, Ubuntu 18.04, and Windows 2022, in addition to those supported by VDDK 7.0.3.1.

For new features in previous VDDK version, see the VDDK 7.0 Release Notes, VDDK 7.0 U1 Release Notes, VDDK 7.0 U2 Release Notes, and VDDK 7.0 U3 Release Notes.

Compatibility Notices

VDDK 7.0.0.3 supports the following operating systems for proxy backup.

• Windows Server 2019
• Windows Server 2016, including versions 1709 and 1803
• Windows Server 2012 and 2012 R2
• Red Hat Enterprise Linux RHEL 7.7, 8.0, and 8.3
• New: RHEL 8.8 was retroactively verified after support in VDDK 8.0.3
• CentOS 7.7 and 8.3
• SUSE Linux Enterprise Server SLES 12 SP5, 15 SP1, and 15.1

New: Best practice for restore with pre-existing snapshot. When a backed-up VM had snapshots, disaster recovery software can restore a fresh VM with its pre-existing snapshots in place. However for partial file recovery, or to recover a VM back to a point in time, it is difficult to determine how to restore a VM that has an existing snapshot. Should parts of the snapshot be restored to a previous state (if applicable), or only the VM by ignoring the snapshot? Certain backup-restore applications do not handle this situation well; snapshot contention causes a GenericVmConfigFault. One good solution is for customers to delete any pre-existing snapshots before recovery, especially if not needed. This is mandatory for SAN transport recovery, anyway. Restore applications could refuse to recover a VM until any pre-existing snapshot is deleted. If not, a customer work-around is to recover the VM to a different location, avoiding the issue, then retain the recovered VM and delete the VM with pre-existing snapshot.

vVol and vSAN datastores do not support SAN mode transport. Since VDDK 6.7, SAN transport is explicitly rejected for vSAN and vVols.

Recently Resolved Issues

New: The VDDK 7.0.3.3 release resolves the following issues.

• Network connection errors appeared permanent and non-retryable.

  VixDiskLib_Open now reports a retryable error for network connection issues. Backup applications can handle and react to the VIX_E_HOST_NETWORK_CONN_REFUSED or VIX_E_HOST_SERVER_SHUTDOWN errors accordingly.

The VDDK 7.0.3.2 release resolved the following issues.

• NAS backup regression with Windows VMs.

  VDDK on vSphere 7.0 U3 had a regression where backup from snapshot failed on Windows hosts that were saving to NAS, such as NetApp servers, with error “You do not have access rights to this [log] file.” The cause was a permission mapping error between POSIX and Windows, triggered by a U3 printer logging change that turned out to have bad side-effects. The printer logging change was backed out for this release.

• Better folder cleanup before Close function.

  In some cases, for instance when vCenter Server fails to respond for backup, the backup folder then contains temporary files so it cannot be deleted. This causes subsequent HotAdd backup jobs to fail. The fix in this release is to have the internal function MountCleanup() delete the backup folder and temporary file(s) to prevent subsequent failures.

• Thread contention reduced for large protection groups.

  VMware Cloud Disaster Recovery can back up many VMs in a protection group, and VixDiskLib_ConnectEx() gets called in multiple threads for each VM, so thread contention can result in the error, “Advanced transport modes not available for opening moRef=vm-NN.” As sizes of protection groups increase, customers encounter this issue more frequently. The fix in this release is to wait for all threads to start before initializing backup.

• Open source libraries upgraded.

  The Open SSL library openssl has been upgraded to version 1.0.2ze. The data compression library Zlib has been upgraded to version 1.2.12.

• Configuration options for NFC asynchronous I/O.

  Customers do not need to change the defaults, but if they encounter NBD performance issues, four buffer settings can be changed under vixDiskLib.nfcAio.SocketOption in the VDDK configuration file. On Linux, various socket buffer sizes have minimal performance impact, but on Windows changing them might yield good benefits. Software providers can assist their customers doing so.

Known Issues and Workarounds

These are unresolved issues known at this time.

• On VMC with NFS, Storage vMotion may conflict with backup.

  During backup a VM's disks are locked against removal. If Storage vMotion is requested against that VM, VM disks remain afterwards, and must be removed manually. The longer backup takes, the higher the likelihood of this occurring. Customers should avoid Storage vMotion during the backup window, but if not, they can find VMDKs not associated with VM or FCD, and remove them.

• Linked clone problems with HotAdd backup on vVol datastores.

  If backup software creates a linked clone target VM from a linked clone VM on a vVol datastore, then performs a backup using HotAdd transport, the proxy VM might become invalid when opening a disk on that target VM. This is a regression from VDDK 7.0.2 to 7.0.3. One alternative is to create the linked clone target VM from a full-clone source VM, rather than from a linked clone VM. Another alternative is to choose a transport mode other than HotAdd.

• Clean-up function not working with default tmpDirectory.

  With a default temporary directory, the folder name can change from backup to backup, if the backup job is a new OS process, so the VixDiskLib_Cleanup function might not clean up everything left behind. To avoid this, programs should set tmpDirectory in the configuration file.