openstack-manuals/doc/config-reference/block-storage/drivers/vmware-vmdk-driver.xml
Stephen Gordon 1960a07f73 Mark VMware ESX VMDK driver as deprecated
Change-Id: I4e6c0f2318a7195c0d3b5d2f5985f1c8d544077d
Closes-Bug: #1292100
2014-04-12 19:09:07 -04:00

206 lines
9.3 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section xml:id="vmware-vmdk-driver"
xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
<title>VMware VMDK driver</title>
<para>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.</para>
<warning>
<para>
The VMware ESX VMDK driver is deprecated as of the Icehouse release
and may be removed in Juno or a subsequent release. The VMware
vCenter VMDK driver continues to be fully supported.
</para>
</warning>
<simplesect>
<title>Functional context</title>
<para>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.</para>
<para>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.</para>
<para>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.</para>
</simplesect>
<simplesect>
<title>Configuration</title>
<para>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.</para>
<para>For example, in the <filename>nova.conf</filename> file,
use this option to define the Compute driver:</para>
<programlisting>compute_driver=vmwareapi.VMwareVCDriver</programlisting>
<para>In the <filename>cinder.conf</filename> file, use this
option to define the volume driver:</para>
<programlisting>volume_driver=cinder.volume.drivers.vmware.vmdk.VMwareVcVmdkDriver</programlisting>
<para>The following table lists various options that the
drivers support for the OpenStack Block Storage
configuration (<filename>cinder.conf</filename>):</para>
<xi:include href="../../../common/tables/cinder-vmware.xml"/>
</simplesect>
<simplesect>
<title>VMDK disk type</title>
<para>The VMware VMDK drivers support the creation of VMDK
disk files of type <literal>thin</literal>, <literal>thick</literal>,
or <literal>eagerZeroedThick</literal>. Use the
<code>vmware:vmdk_type</code> 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:</para>
<table rules="all">
<caption>Extra spec entry to VMDK disk file type
mapping</caption>
<thead>
<tr>
<td>Disk file type</td>
<td>Extra spec key</td>
<td>Extra spec value</td>
</tr>
</thead>
<tbody>
<tr>
<td>thin</td>
<td>vmware:vmdk_type</td>
<td>thin</td>
</tr>
<tr>
<td>thick</td>
<td>vmware:vmdk_type</td>
<td>thick</td>
</tr>
<tr>
<td>eagerZeroedThick</td>
<td>vmware:vmdk_type</td>
<td>eagerZeroedThick</td>
</tr>
</tbody>
</table>
<para>If no <code>vmdk_type</code> extra spec entry is
specified, the default disk file type is
<literal>thin</literal>.</para>
<para>The example below shows how to create a
<code>thick</code> VMDK volume using the appropriate
<code>vmdk_type</code>:</para>
<screen>
<prompt>$</prompt> <userinput>cinder type-create thick_volume</userinput>
<prompt>$</prompt> <userinput>cinder type-key thick_volume set vmware:vmdk_type=thick</userinput>
<prompt>$</prompt> <userinput>cinder create --volume-type thick_volume --display-name volume1 1</userinput>
</screen>
</simplesect>
<simplesect>
<title>Clone type</title>
<para>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
<literal>full</literal> and
<literal>linked/fast</literal>. The clone type is
specified using the <code>vmware:clone_type</code> extra
spec key with the appropriate value. The following table
captures the mapping for clone types:</para>
<table rules="all">
<caption>Extra spec entry to clone type mapping</caption>
<thead>
<tr>
<td>Clone type</td>
<td>Extra spec key</td>
<td>Extra spec value</td>
</tr>
</thead>
<tbody>
<tr>
<td>full</td>
<td>vmware:clone_type</td>
<td>full</td>
</tr>
<tr>
<td>linked/fast</td>
<td>vmware:clone_type</td>
<td>linked</td>
</tr>
</tbody>
</table>
<para>If not specified, the default clone type is
<literal>full</literal>.</para>
<para>The following is an example of linked cloning from
another source volume:</para>
<screen>
<prompt>$</prompt> <userinput>cinder type-create fast_clone</userinput>
<prompt>$</prompt> <userinput>cinder type-key fast_clone set vmware:clone_type=linked</userinput>
<prompt>$</prompt> <userinput>cinder create --volume-type fast_clone --source-volid 25743b9d-3605-462b-b9eb-71459fe2bb35 --display-name volume1 1</userinput>
</screen>
<para>Note: The VMware ESX VMDK driver ignores the extra spec
entry and always creates a <literal>full</literal>
clone.</para>
</simplesect>
<simplesect>
<title>Supported operations</title>
<para>The following operations are supported by the VMware
vCenter and ESX VMDK drivers:</para>
<itemizedlist>
<listitem>
<para>Create volume</para>
</listitem>
<listitem>
<para>Create volume from another source volume.
(Supported only if source volume is not attached
to an instance.)</para>
</listitem>
<listitem>
<para>Create volume from snapshot</para>
</listitem>
<listitem>
<para>Create volume from glance image</para>
</listitem>
<listitem>
<para>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.)</para>
</listitem>
<listitem>
<para>Detach volume</para>
</listitem>
<listitem>
<para>Create snapshot (Allowed only if volume is not
attached to an instance.)</para>
</listitem>
<listitem>
<para>Delete snapshot (Allowed only if volume is not
attached to an instance.)</para>
</listitem>
<listitem>
<para>Upload as image to glance (Allowed only if
volume is not attached to an instance.)</para>
</listitem>
</itemizedlist>
<note>
<para>Although the VMware ESX VMDK driver supports these
operations, it has not been extensively tested.</para>
</note>
</simplesect>
<simplesect>
<title>Data store selection</title>
<para>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
<literal>(1 - freespace/totalspace)</literal>.</para>
</simplesect>
</section>