Virtual Disk Development Kit Release Notes

VDDK 7.0.3.2 | 28 July 2022 | ESXi build 7.0 U3g, VDDK build 20134304
For vSphere 7.0 U3g | Last document update 28 July 2022
Check back for additions and updates to these release notes.

Contents

About the Virtual Disk Development Kit

The Virtual Disk Development Kit (VDDK) 7.0.3.2 is an bug-fix update to support vSphere 7.0 U3 patches 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.2 offers the following New features:

  • Fix to reduce the number of connections from VDDK to vCenter Server, as requested by backup partners.
  • Corrected HotAdd failures due to mismatch of controller ordering between Linux proxy OS and vSphere, as requested by customers.
  • New configuration options for buffer settings of NFC asynchronous I/O. See resolved issues below.
  • VDDK 7.0.3.2 supports 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

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.

Missing from documentation (until 7.0.1) was this caveat about multithreading: QueryAllocatedBlocks should be called in the same thread as open and close disk, not from read and write worker threads.

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.2 release resolves the following issues.

  • Open source libraries upgraded.

    The Open SSL library openssl is upgraded to version 1.0.2ze. The data compression library Zlib is 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, they can change change four buffer settings 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.

The VDDK 7.0.3.1 release resolved the following issues.

  • Open SSL library and XML library upgraded.

    The Open SSL library openssl was upgraded to version 1.0.2za, and the XML streaming library libexpat to version 2.4.4.

  • NBDSSL failed to open encrypted FCD with IPv6 enabled.

    In secure NBD (NBDSSL) transport mode, encrypted First Class Disk (FCD) could not be opened if IPv6 was enabled on the network. This regression discovered in VDDK 7.0.2 is fixed in this release.

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.

 

Copyright © 2022 VMware, Inc. All rights reserved.