Improved Virtual Disk, also known as First Class Disk (FCD), provides storage lifecycle management on virtual disks, independent of virtual machines. An IVD may be created natively using the IVD interfaces or an existing virtual disk may be promoted to an IVD.

Improved Virtual Disk is a named virtual disk not associated with a VM. The vSphere API for handling IVD is called VSLM, virtual storage lifecycle management.

In vSphere 6.5, VDDK supported the backup of IVD in attached mode, but not in detached mode. To back up IVD, programs had to attach the IVD to a dummy VM (such as one without a guest OS) and then back up the VM.

In vSphere 6.7, VDDK supports the backup of detached IVD, in any transport mode. Detached IVD is neither related to nor attached to a VM. It is identified by a combination of its UUID and the datastore ID where it resides. An IVD must be attached to a VM for regular I/O, but not for snapshot based backup.

Improved Virtual Disks are identified by UUID. This UUID is globally unique and the primary identifier for the IVD. The UUID remains valid even if its IVD is relocated or snapshotted. IVD operations are performed using the VStorageObjectManagerBase managed object, extended for either ESXi hosts or vCenter Server. See the vSphere API Reference for details.

Create and Delete: IVDs can be created using the createDisk_Task method. An existing VMDK can be promoted to IVD using the registerDisk method. Once a disk has been registered as an IVD it cannot be unregistered, however registering a disk as an IVD has no impact other than enabling the VSLM APIs to manage them.

Snapshot: IVD snapshots use the same underlying mechanisms as regular snapshots and have the same restrictions as regular snapshots. IVD snapshots are independent of VM snapshots. Each IVD snapshot receives a separate snapshot ID. Snapshots are managed using the VStorageObjectManager specific createSnapshot_Task and deleteSnapshot_Task methods. You can revert an IVD to a given snapshot using the RevertVStorageObject_Task method. Reverting an IVD removes all snapshots after the selected snapshot. To access data at the time of the snapshot without discarding subsequent snapshots, you can use the VStorageObjectManagerCreateDiskFromSnapshot method or VADP restore.

Backup and Restore: IVDs that are not attached to VMs can be backed up using the VADP interfaces. For backup applications, the best practice is to back up VMDKs and IVDs attached to the VMs, and also back up IVDs that are not attached to a VM.

IVDs can be listed on a per-datastore basis. The recommended practice is to iterate across the list of datastores from vCenter, get the IVDs for each datastore, then perform a backup of each IVD. VADP can back up both attached and detached IVDs.

Use the Datacenter managed object's datastore property to list all datastores in a datacenter. For each datastore, use the listVStorageObject method to list the IVDs. For each IVD, use the VStorageObject.getConfig.getId API to retrieve the IVD's ID. The IVD ID is used in connParams-> below. The IVD snapshot ID is used in the connParams->vStorageObjSpec.ssid to specify the snapshot to back up from.

VDDK 6.7 has a new union in the VixDiskLibConnectParams structure, and new function calls to allocate and free the structure, VixDiskLib_AllocateConnectParams() and VixDiskLib_FreeConnectParams(). The new typedef is a union of:

vmxSpec, the traditional specification string for a VM.

VixDiskLibVStorageObjectSpec specifying the IVD's UUID, datastore MoRef, and snapshot UUID.

VixDiskLib_AllocateConnectParams() is the recommended way to allocate an instance of VixDiskLibConnectParams. Programs can allocate VixDiskLibConnectParams as before, although then they cannot use new features in 6.7 such as detached IVD.

Except for connection parameters, VDDK code remains the same. All transport modes may be used. Here is sample C++ code to allocate and initialize the connect parameters structure:

auto connParams = VixDiskLib_AllocateConnectParams();
connParams-> = "XXXXXX" // IVD UUID
connParams->vStorageObjSpec.datastoreMoRef = "datastore-N" // datastore
connParams->vStorageObjSpec.ssid = "XXXXXX" // IVD snapshot UUID
VixDiskLib_FreeConnectParams(connParams); // free connect params near end

For a vmxSpec, here is a sample of legacy C++ code, and a revision:

// old:
VixDiskLibConnectParams connParams;
connParams.vmxSpec = "moref=vm-XX"; // vm moref
// new:
auto connParams = VixDiskLib_AllocateConnectParams;
connParams->specType = VIXDISKLIB_SPEC_VMX;
connParams->vmxSpec = "moref=vm-XX"; // vm moref
VixDiskLib_FreeConnectParams(connParams); // free connect params near end

Subsequently, VixDiskLib_Open ignores its disk path parameter because path location is determined by VixDiskLibVStorageObjectSpec. The snapshot UUID is specified in VixDiskLibVStorageObjectSpec, so the disk path is invisible to the customer anyway. Consequently programs can pass NULL as the disk path parameter to VixDiskLib_Open. Programs can also pass an IVD's UUID as the path parameter:

VixDiskLib_Open(const VixDiskLibConnection connection,
                const char *path,
                uint32 flags,
                VixDiskLibHandle *diskHandle);

However for the VixMntapi open disks call, passing a null diskNames parameter may cause a crash. Programs should pass the IVD's UUID only, and specify numberOfDisks = 1.

VixMntapi_OpenDisks(VixDiskLibConnection connection,
                    const char *diskNames[],
                    size_t numberOfDisks,
                    uint32 openFlags,
                    VixDiskSetHandle *handle);

The following managed objects and tasks are available in vSphere for manipulating IVD storage. For details, see the vSphere Web Services API Reference on under the vSphere Management SDK.

HostVStorageObjectManager manages IVD when connected to an ESXi host.

VcenterVStorageObjectManager manages IVD when connected to a vCenter Server.

VirtualMachine.AttachDisk_Task() attaches IVD to a VM.

VirtualMachine.DetachDisk_Task() detaches IVD from the VM.

The behavior of IVD with changed block tracking (CBT) differs from that of a regular VMDK disk.


Attaching an IVD with CBT disabled (the default) to a VM with CBT enabled causes CBT on the IVD to become enabled. However, detaching that IVD from the VM does not disable CBT.


Attaching an IVD with CBT enabled to a VM with CBT disabled throws an error, unless the IVD is attached as "independent nonpersistent" disk.

Use ReconfigVM_Task and connect the disk with the diskMode set to independent_nonpersistent in the backing info. (VirtualDiskSeSparseBackingInfo, VirtualDiskFlatVer2BackingInfo, VirtualDiskRawDiskMappingVer1BackingInfo and VirtualDiskSparseVer2BackingInfo support this mode.)

An IVD can be attached to more than one VM.

When your program calls VixDiskLib_PrepareForAccess, VDDK disables the vSphere API method RelocateVM_Task for all attached VMs, one after another. If an error occurs while disabling, VMs whose relocate method was disabled remain disabled, whereas subsequent VMs can still be relocated. Programs should call VixDiskLib_EndAccess to re-enable the relocate method, regardless of VixDiskLib_PrepareForAccess return status. Otherwise vMotion or Storage vMotion could fail for the remaining disabled VMs.

In the development kit, see lines in the vixDiskLibSample.cpp program where connection parameters are allocated with the VixDiskLib_AllocateConnectParams() call.