VMware VMDK driver enables management of cinder volume on VMware vCenter Server or ESX managed datastore. Cinder volume is backed by VMDK files on the datastore. Two cinder drivers for VMware vCenter server and ESX are provided. Appropriate driver must be configured when using VMware server. For attach/detach operation to an instance, the driver works as expected only with the VMware driver for nova and it does not work with other nova drivers. Both nova and cinder drivers must be configured to the same server. The following table captures the configuration mapping:

Cinder-Nova configuration mapping with VMware server

VMware server	Nova driver	Cinder driver
vCenter server	vmwareapi.VMwareVCDriver	cinder.volume.drivers.vmware.vmdk.VMwareVcVmdkDriver
ESX/ESXi server	vmwareapi.VMwareESXDriver	cinder.volume.drivers.vmware.vmdk.VMwareEsxVmdkDriver

The following are mandatory properties to be specified in the configuration file:

Mandatory properties

Name	Description
vmware_host_ip	IP address for connecting to VMware ESX/VC server
vmware_host_username	Username for authenticating with VMware ESX/VC server
vmware_host_password	Password for authenticating with VMware ESX/VC server

The following are optional properties to be specified in the configuration file:

Optional properties

Name	Default value	Description
vmware_wsdl_location	None	Optional VIM service WSDL Location e.g http://server/vimService.wsdl. Optional over-ride to default location for bug work-arounds.
vmware_api_retry_count	10	Number of times VMware ESX/VC server API must be retried upon connection related issues
vmware_task_poll_interval	5	The interval used for polling remote tasks invoked on VMware ESX/VC server
vmware_volume_folder	cinder-volumes	Name for the folder in the VC datacenter that will contain cinder volumes
vmware_image_transfer_timeout_secs	7200	Timeout in seconds for VMDK volume transfer between Cinder and Glance
vmware_max_objects_retrieval	100	Max number of objects to be retrieved per batch. Query results will be obtained in batches from the server and not in one shot. Server may still limit the count to something less than the configured value.

VMwareVcVmdkDriver and VMwareEsxVmdkDriver support creating VMDK disk file of types: thin, thick and eagerZeroedThick. VMDK disk file type can be specified via volume type extra specs. By using any volume type with appropriate extra spec for volume creation, the driver creates one of the above VMDK disk file type. The following captures extra spec entry to VMDK disk file type mapping:

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

When no volume type is used or if none of the above extra spec entry is found in the volume type, then the default disk file type used is thin. Example: creation of thick VMDK volume $ 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 VMwareVcVmdkDriver supports clone types: full and linked/fast while creating volume from another source volume or from a snapshot point. Clone type can be specified via volume type extra specs. By using volume type with appropriate extra spec for creating volume from another source volume or from a snapshot point, the driver creates a full clone or a linked clone. The following captures extra spec entry to clone type mapping:

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

When no volume type is used or if none of the above extra spec entry is found in the volume type, then the default clone type is full. Example: 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: VMwareEsxVmdkDriver ignores the extra spec entry and always creates a full clone while creating volume from another source volume or from a snapshot point. The following operations are supported by VMwareVcVmdkDriver and VMwareEsxVmdkDriver: 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. The driver chooses datastore that can accommodate for the volume space and has highest freespace/totalspace metric value. When the volume is being attached to an instance, the driver tries to place the volume under instance's ESX host on a datastore selected based on the above strategy.