White Papers

VMware integrations
22 Dell EMC PowerVault ME4 Series and VMware vSphere | 3922-BP-VM
7.1.3 Hardware-assisted locking
To protect Virtual Machine File System (VMFS) metadata, the hardware-assisted locking primitive provides a
more granular method than SCSI reservations. Previously, whenever a virtual machine powered on, powered
off, grew a thin provisioned virtual disk, or was moved with vMotion to another host, a SCSI reservation lock
would be issued by the ESXi host to the underlying volume of the datastore. This prevented other hosts from
also issuing a SCSI reservation to service a similar request. While SCSI reservations are short-lived, the
impact can be noticed when powering on a large number of virtual machines simultaneously, as typically
observed in a virtual desktop infrastructure (VDI) environment. The hardware-assisted locking primitive
resolves this by working with the ME4 Series array to lock only the necessary blocks rather than the entire
volume. This enables other hosts to perform similar operations against that same volume at the same time.
7.1.4 Thin provisioning space reclamation
The thin provisioning space reclamation primitive, also known as unmap, enables thin-provisioned datastores
to be rethinned to only consume the actual space they are consuming on the array. This frees up space on
the array that has been deleted by ESXi, allowing thin-provisioned volumes to remain thin and reducing
overall storage costs. Traditionally, the size of a thin-provisioned volume, as shown at the storage layer,
reflects the maximum space consumption that occurred at some point since it was created. This is because
ESXi did not inform the array that particular blocks of data had been deleted and no longer needed to be
stored by the array. The T10 SCSI primitive unmap enables this information to be communicate to the array,
through the SCSI storage stack. This unmap primitive is referred to as thin provisioning space reclamation by
VMware.
With the release of vSphere 6.7, VMware updated the unmap API to run automatically in the background
without user intervention as part of VMFS-6. This is dependent upon arrays using 1 MB or smaller pages. The
ME4 Series array uses 4 MB pages, and therefore is incompatible with automatic unmap.
The command for running unmap is a part of the esxcli command set of the ESXi operating system. This
enables the command to be accessed from many scripting tools and to be called remotely with vSphere vCLI
or PowerCLI. The syntax of the unmap command is as follows:
esxcli storage vmfs unmap --volume-label=volume_label
Note: VMware recommends limiting unmap operations to an off-peak operating timeframe.
7.2 VMware Storage I/O Control
Storage I/O Control (SIOC) ensures that the excessive storage I/O demands of a particular VMDK do not
negatively impact the storage I/O needs of other VMDKs residing on the same datastore. Previously, this has
been resolved though administrative tasks such as careful VM placement, reactive monitoring of VMDK I/O,
and oversizing of the environment to handle occasional I/O spikes.
With SIOC, the reactive monitoring task is conducted by vSphere across all ESXi hosts and the reactive
action is performed automatically and instantaneously by vSphere, enabling administrators to more efficiently
utilize their storage environments.
The advantages of using Storage I/O Control include the following:
Performance protection: SIOC ensures that all VMDKs receive a fair share or an assigned share of I/O
needs, regardless of the I/O they demand during period of congestion.