Atom feed of this document
Icehouse -  Icehouse -  Icehouse -  Icehouse -  Icehouse -  Icehouse -  Icehouse -  Icehouse - 

 VMware VMDK driver

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 that use any VMware-compatible storage technology such as NFS, iSCSI, FiberChannel, and vSAN.


The VMware ESX VMDK driver is deprecated as of the Icehouse release and might be removed in Juno or a subsequent release. The VMware vCenter VMDK driver continues to be fully supported.

 Functional context

The VMware VMDK driver connects to vCenter, through which it can dynamically access all the data stores visible from the ESX hosts in the managed cluster.

When you create a volume, the VMDK driver creates a VMDK file on demand. The VMDK file creation completes only when the volume is subsequently attached to an instance, because the set of data stores visible to the instance determines where to place the volume.

The running vSphere VM is 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.

In the nova.conf file, use this option to define the Compute driver:


In the cinder.conf file, use this option to define the volume driver:


The following table lists various options that the drivers support for the OpenStack Block Storage configuration (cinder.conf):

Table 1.24. Description of configuration options for vmware
Configuration option = Default value Description
vmware_api_retry_count = 10 (IntOpt) Number of times VMware ESX/VC server API must be retried upon connection related issues.
vmware_host_ip = None (StrOpt) IP address for connecting to VMware ESX/VC server.
vmware_host_password = None (StrOpt) Password for authenticating with VMware ESX/VC server.
vmware_host_username = None (StrOpt) Username for authenticating with VMware ESX/VC server.
vmware_host_version = None (StrOpt) Optional string specifying the VMware VC server version. The driver attempts to retrieve the version from VMware VC server. Set this configuration only if you want to override the VC server version.
vmware_image_transfer_timeout_secs = 7200 (IntOpt) Timeout in seconds for VMDK volume transfer between Cinder and Glance.
vmware_max_objects_retrieval = 100 (IntOpt) 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.
vmware_task_poll_interval = 5 (IntOpt) The interval (in seconds) for polling remote tasks invoked on VMware ESX/VC server.
vmware_volume_folder = cinder-volumes (StrOpt) Name for the folder in the VC datacenter that will contain cinder volumes.
vmware_wsdl_location = None (StrOpt) Optional VIM service WSDL Location e.g http://<server>/vimService.wsdl. Optional over-ride to default location for bug work-arounds.

 VMDK disk type

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:

Table 1.25. 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 you do not specify a vmdk_type extra spec entry, the default disk file type is thin.

The following example shows how to create a thick VMDK volume by 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

 Clone type

With the VMware VMDK drivers, you can create a volume from another source volume or a snapshot point. The VMware vCenter VMDK driver supports the full and linked/fast clone types. Use the vmware:clone_type extra spec key to specify the clone type. The following table captures the mapping for clone types:

Table 1.26. 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 you do not specify the clone type, the default is full.

The following example shows 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

The VMware ESX VMDK driver ignores the extra spec entry and always creates a full clone.

 Use vCenter storage policies to specify back-end data stores

This section describes how to configure back-end data stores using storage policies. In vCenter, you can create one or more storage policies and expose them as a Block Storage volume-type to a vmdk volume. The storage policies are exposed to the vmdk driver through the extra spec property with the vmware:storage_profile key.

For example, assume a storage policy in vCenter named gold_policy. and a Block Storage volume type named vol1 with the extra spec key vmware:storage_profile set to the value gold_policy. Any Block Storage volume creation that uses the vol1 volume type places the volume only in data stores that match the gold_policy storage policy.

The Block Storage back-end configuration for vSphere data stores is automatically determined based on the vCenter configuration. If you configure a connection to connect to vCenter version 5.5 or later in the cinder.conf file, the use of storage policies to configure back-end data stores is automatically supported.


You must configure any data stores that you configure for the Block Storage service for the Compute service.


Procedure 1.6. To configure back-end data stores by using storage policies

  1. In vCenter, tag the data stores to be used for the back end.

    OpenStack also supports policies that are created by using vendor-specific capabilities; for example vSAN-specific storage policies.


    The tag value serves as the policy. For details, see the section called “Storage policy-based configuration in vCenter”.

  2. Set the extra spec key vmware:storage_profile in the desired Block Storage volume types to the policy name that you created in the previous step.

  3. Optionally, for the vmware_host_version parameter, enter the version number of your vSphere platform. For example, 5.5.

    This setting overrides the default location for the corresponding WSDL file. Among other scenarios, you can use this setting to prevent WSDL error messages during the development phase or to work with a newer version of vCenter.

  4. Complete the other vCenter configuration parameters as appropriate.


The following considerations apply to configuring SPBM for the Block Storage service:

  • Any volume that is created without an associated policy (that is to say, without an associated volume type that specifies vmware:storage_profile extra spec), there is no policy-based placement for that volume.

 Supported operations

The VMware vCenter and ESX VMDK drivers support these operations:

  • 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.

 Storage policy-based configuration in vCenter

You can configure Storage Policy-Based Management (SPBM) profiles for vCenter data stores supporting the Compute, Image Service, and Block Storage components of an OpenStack implementation.

In a vSphere OpenStack deployment, SPBM enables you to delegate several data stores for storage, which reduces the risk of running out of storage space. The policy logic selects the data store based on accessibility and available storage space.


  • Determine the data stores to be used by the SPBM policy.

  • Determine the tag that identifies the data stores in the OpenStack component configuration.

  • Create separate policies or sets of data stores for separate OpenStack components.

 Create storage policies in vCenter


Procedure 1.7. To create storage policies in vCenter

  1. In vCenter, create the tag that identifies the data stores:

    1. From the Home screen, click Tags.

    2. Specify a name for the tag.

    3. Specify a tag category. For example, spbm-cinder.

  2. Apply the tag to the data stores to be used by the SPBM policy.


    For details about creating tags in vSphere, see the vSphere documentation.

  3. In vCenter, create a tag-based storage policy that uses one or more tags to identify a set of data stores.


    You use this tag name and category when you configure the *.conf file for the OpenStack component. For details about creating tags in vSphere, see the vSphere documentation.

 Data store selection

If storage policy is enabled, the driver initially selects all the data stores that match the associated storage policy.

If two or more data stores match the storage policy, the driver chooses a data store that is connected to the maximum number of hosts.

In case of ties, the driver chooses the data store with lowest space utilization, where space utilization is defined by the (1-freespace/totalspace) metric.

These actions reduce the number of volume migrations while attaching the volume to instances.

The volume must be migrated if the ESX host for the instance cannot access the data store that contains the volume.

Questions? Discuss on
Found an error? Report a bug against this page

loading table of contents...