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.

Note

The VMware VMDK driver requires vCenter version 5.1 at minimum.

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. The reason for this requirement is that data stores visible to the instance determine where to place the volume. Before the service creates the VMDK file, attach a volume to the target instance.

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.

With the update to ESX version 6.0, the VMDK driver now supports NFS version 4.1.

Configuration

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:

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):

Description of VMware configuration options

Configuration option = Default value

Description

[DEFAULT]

vmware_adapter_type = lsiLogic

(String) Default adapter type to be used for attaching volumes.

vmware_api_retry_count = 10

(Integer) Number of times VMware vCenter server API must be retried upon connection related issues.

vmware_ca_file = None

(String) CA bundle file to use in verifying the vCenter server certificate.

vmware_cluster_name = None

(Multi-valued) Name of a vCenter compute cluster where volumes should be created.

vmware_connection_pool_size = 10

(Integer) Maximum number of connections in http connection pool.

vmware_host_ip = None

(String) IP address for connecting to VMware vCenter server.

vmware_host_password = None

(String) Password for authenticating with VMware vCenter server.

vmware_host_port = 443

(Port number) Port number for connecting to VMware vCenter server.

vmware_host_username = None

(String) Username for authenticating with VMware vCenter server.

vmware_host_version = None

(String) Optional string specifying the VMware vCenter server version. The driver attempts to retrieve the version from VMware vCenter server. Set this configuration only if you want to override the vCenter server version.

vmware_image_transfer_timeout_secs = 7200

(Integer) Timeout in seconds for VMDK volume transfer between Cinder and Glance.

vmware_insecure = False

(Boolean) If true, the vCenter server certificate is not verified. If false, then the default CA truststore is used for verification. This option is ignored if “vmware_ca_file” is set.

vmware_max_objects_retrieval = 100

(Integer) 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 = 2.0

(Floating point) The interval (in seconds) for polling remote tasks invoked on VMware vCenter server.

vmware_tmp_dir = /tmp

(String) Directory where virtual disks are stored during volume backup and restore.

vmware_volume_folder = Volumes

(String) Name of the vCenter inventory folder that will contain Cinder volumes. This folder will be created under “OpenStack/<project_folder>”, where project_folder is of format “Project (<volume_project_id>)”.

vmware_wsdl_location = None

(String) 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 file types thin, lazyZeroedThick (sometimes called thick or flat), or eagerZeroedThick.

A thin virtual disk is allocated and zeroed on demand as the space is used. Unused space on a Thin disk is available to other users.

A lazy zeroed thick virtual disk will have all space allocated at disk creation. This reserves the entire disk space, so it is not available to other users at any time.

An eager zeroed thick virtual disk is similar to a lazy zeroed thick disk, in that the entire disk is allocated at creation. However, in this type, any previous data will be wiped clean on the disk before the write. This can mean that the disk will take longer to create, but can also prevent issues with stale data on physical media.

Use the vmware:vmdk_type extra spec key with the appropriate value to specify the VMDK disk file type. This table shows 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

lazyZeroedThick

vmware:vmdk_type

thick

eagerZeroedThick

vmware:vmdk_type

eagerZeroedThick

If you do not specify a vmdk_type extra spec entry, the disk file type will default to thin.

The following example shows how to create a lazyZeroedThick VMDK volume by using the appropriate vmdk_type:

$ openstack volume type create THICK_VOLUME
$ openstack volume type set --property vmware:vmdk_type=thick THICK_VOLUME
$ openstack volume create --size 1 --type THICK_VOLUME VOLUME1

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:

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 a source volume, which is created from an image:

$ openstack volume type create FAST_CLONE
$ openstack volume type set --property vmware:clone_type=linked FAST_CLONE
$ openstack volume create --size 1 --type FAST_CLONE --image MYIMAGE SOURCE_VOL
$ openstack volume create --size 1 --source SOURCE_VOL DEST_VOL

Adapter type

The VMware vCenter VMDK driver supports the adapter types LSI Logic Parallel, BusLogic Parallel, LSI Logic SAS, VMware Paravirtual and IDE for volumes. Use the vmware:adapter_type extra spec key to specify the adapter type. The following table captures the mapping for adapter types:

Extra spec entry to adapter type mapping

Adapter type

Extra spec key

Extra spec value

BusLogic Parallel

vmware:adapter_type

busLogic

IDE

vmware:adapter_type

ide

LSI Logic Parallel

vmware:adapter_type

lsiLogic

LSI Logic SAS

vmware:adapter_type

lsiLogicsas

VMware Paravirtual

vmware:adapter_type

paraVirtual

If you do not specify the adapter type, the default is the value specified by the config option vmware_adapter_type.

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 5.5 and greater, 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.

Note

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

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.

    Note

    The tag value serves as the policy. For details, see 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.

Note

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 VMDK driver supports these operations:

  • Create, delete, attach, and detach volumes.

    Note

    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.

  • Create, list, and delete volume snapshots.

    Note

    Allowed only if volume is not attached to an instance.

  • Create a volume from a snapshot.

    Note

    The vmdk UUID in vCenter will not be set to the volume UUID if the vCenter version is 6.0 or above and the extra spec key vmware:clone_type in the destination volume type is set to linked.

  • Copy an image to a volume.

    Note

    Only images in vmdk disk format with bare container format are supported. The vmware_disktype property of the image can be preallocated, sparse, streamOptimized or thin.

  • Copy a volume to an image.

    Note

    • Allowed only if the volume is not attached to an instance.

    • This operation creates a streamOptimized disk image.

  • Clone a volume.

    Note

    • Supported only if the source volume is not attached to an instance.

    • The vmdk UUID in vCenter will not be set to the volume UUID if the vCenter version is 6.0 or above and the extra spec key vmware:clone_type in the destination volume type is set to linked.

  • Backup a volume.

    Note

    This operation creates a backup of the volume in streamOptimized disk format.

  • Restore backup to new or existing volume.

    Note

    Supported only if the existing volume doesn’t contain snapshots.

  • Change the type of a volume.

    Note

    This operation is supported only if the volume state is available.

  • Extend a volume.

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.

Prerequisites

  • 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

  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.

    Note

    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.

    Note

    For details about creating storage policies 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) meters.

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.