Use the VMware VMDK driver to enable management of the OpenStack Block Storage volumes on vCenter-managed data stores. Volumes are backed by VMDK files on data stores using any VMware-compatible storage technology such as NFS, iSCSI, FiberChannel, and vSAN. The VMware VMDK driver connects to vCenter, through which it can dynamically access all the datastores visible from the ESX hosts in the managed cluster. When you create a volume, the VMDK driver creates a VMDK file on demand. The creation of this VMDK file is completed only when the volume is subsequently attached to an instance, because the set of datastores visible to the instance determines where to place the volume. The running vSphere VM is then automatically reconfigured to attach the VMDK file as an extra disk. Once attached, you can log in to the running vSphere VM to rescan and discover this extra disk. The recommended volume driver for OpenStack Block Storage is the VMware vCenter VMDK driver. When you configure the driver, you must match it with the appropriate OpenStack Compute driver from VMware and both drivers must point to the same server. For example, in the nova.conf file, use this option to define the Compute driver: compute_driver=vmwareapi.VMwareVCDriver In the cinder.conf file, use this option to define the volume driver: volume_driver=cinder.volume.drivers.vmware.vmdk.VMwareVcVmdkDriver The following table lists various options that the drivers support for the OpenStack Block Storage configuration (cinder.conf): The VMware VMDK drivers support the creation of VMDK disk files of type thin, thick, or eagerZeroedThick. Use the vmware:vmdk_type extra spec key with the appropriate value to specify the VMDK disk file type. The following table captures the mapping between the extra spec entry and the VMDK disk file type:

Extra spec entry to VMDK disk file type mapping

Disk file type	Extra spec key	Extra spec value
thin	vmware:vmdk_type	thin
thick	vmware:vmdk_type	thick
eagerZeroedThick	vmware:vmdk_type	eagerZeroedThick

If no vmdk_type extra spec entry is specified, the default disk file type is thin. The example below shows how to create a thick VMDK volume using the appropriate vmdk_type: $ cinder type-create thick_volume $ cinder type-key thick_volume set vmware:vmdk_type=thick $ cinder create --volume-type thick_volume --display-name volume1 1 With the VMware VMDK drivers, you can create a volume from another source volume or from a snapshot point. The VMware vCenter VMDK driver supports clone types full and linked/fast. The clone type is specified using the vmware:clone_type extra spec key with the appropriate value. The following table captures the mapping for clone types:

Extra spec entry to clone type mapping

Clone type	Extra spec key	Extra spec value
full	vmware:clone_type	full
linked/fast	vmware:clone_type	linked

If not specified, the default clone type is full. The following is an example of linked cloning from another source volume: $ cinder type-create fast_clone $ cinder type-key fast_clone set vmware:clone_type=linked $ cinder create --volume-type fast_clone --source-volid 25743b9d-3605-462b-b9eb-71459fe2bb35 --display-name volume1 1 Note: The VMware ESX VMDK driver ignores the extra spec entry and always creates a full clone. The following operations are supported by the VMware vCenter and ESX VMDK drivers: Create volume Create volume from another source volume. (Supported only if source volume is not attached to an instance.) Create volume from snapshot Create volume from glance image Attach volume (When a volume is attached to an instance, a reconfigure operation is performed on the instance to add the volume's VMDK to it. The user must manually rescan and mount the device from within the guest operating system.) Detach volume Create snapshot (Allowed only if volume is not attached to an instance.) Delete snapshot (Allowed only if volume is not attached to an instance.) Upload as image to glance (Allowed only if volume is not attached to an instance.) Although the VMware ESX VMDK driver supports these operations, it has not been extensively tested. When creating a volume, the driver chooses a data store which is connected to maximum number of hosts. This is meant to reduce the number of volume migrations while attaching the volume to instances. The volume needs to be migrated if the instance's ESX host cannot access the data store containing the volume. In case of ties, the data store with lowest space utilization is selected, where space utilization is defined by the metric (1 - freespace/totalspace).