User guide

Technical white paper | HP Enterprise Virtual Array Storage and VMware vSphere 4.x and 5.x configuration best practices
50
Table 13. Differences in versions supporting UNMAP
Feature
ESXi 5.0U1/ESXi 5.1
ESXi 5.5
UNMAP invoked via
Command Line
Command Line
CLI
vmkfstools
esxcli
Uses temp file
YES
YES
Max temp file size
2TB
~62TB
Efficiency
Random
100%
Default reclaim unit
(1MB Block Size)
60% of free capacity
200 Blocks
Recommended reclaim unit (1MB
Block Size)
-
480 (EVA4400/EVA8400)
1280 (P63xx/P65xx)
Capacity Reservation
HIGH
LOW
Maintenance Window required
YES
NO
Support multiple UNMAP descriptors
NO
YES
UNMAP alignment, size and EVA host mode considerations
In order to optimize space reclamation efficiency and performance, ESX’s UNMAP implementation is adaptive. The
implementation leverages the data retrieved from the array SCSI inquiry page B0 (Blocks Limits page) and adjusts ESX
behavior to match the array expected values. Two critical values retrieved in the blocks limits inquiry page are:
• OPTIMAL UNMAP GRANULARITY
• MAXIMUM UNMAP BLOCK COUNT
The EVA advertises an UNMAP optimal unmap granularity that nicely aligns with ESX expected default alignments of 64KiB
and 1MB. Hence, VMware VMFS partitions created with ESXi 5 and aligned on 1MB or upgraded VMFS datastores which
retain their alignment and block size (which typically defaults at 64k) will all function properly with UNMAP on EVA. Note
however that ESX will not issue UNMAP requests to VMFS partitions aligned at offsets other than 64KiB and 1MB on an EVA.
Therefore, it is recommended to have all EVA datastores aligned at 64KiB or 1MB in order to use space reclamation.
Best practice for aligning VMFS volume for use with HP EVA Storage UNMAP
• VMFS datastore must be aligned to either 64KiB or 1MB boundary for use with HP EVA Storage UNMAP integration.
The maximum unmap block count advertises to ESX the maximum unmap request size the array will allow. Requests above
this value will be rejected and have to be retried. Since this value is retrieved directly from the storage system by ESX, no
actions are required by the user to leverage this functionality when using ESX.
In order for ESX to appropriately adapt to the EVA desired UNMAP behavior, it is critical that the ESX hosts accessing the EVA
be set to the VMware host mode in Command View EVA. Failure to do so will lead to unpredictable results.
Note that when RDM volumes are presented to VMs running operating systems that support space reclamation natively,
such as Windows Server 2012, space reclamation within these VMs is not supported. This is because the RDM will be
accessed by ESX using the VMware host mode, and that host mode is not suitable for space reclamation on Windows Server
2012. If you require a virtual machine to perform space reclamation on EVA, at the time of this writing, you must configure
VMDirectPathIO and configure a host with the appropriate host mode for the operating system the virtual machine is
running.
Best practice for host mode configuration
• The VMware host mode must be used on the EVA for proper operation of the UNMAP primitive with ESX.
• UNMAP is not supported by VMs accessing RDM volumes presented to ESX hosts. Use, VMDirectPathIO and give exclusive
access of the volume to the VM with appropriate host mode.