Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax and VMware vSphere Configuration Guide > VMware vSphere Storage APIs for Array Integration
The VAAI primitives are enabled by default on the supported arrays and do not require any user intervention. The primitive, however, can be disabled through the ESXi server if wanted. Full Copy can be disabled or enabled by altering the DataMover.HardwareAcceleratedMove setting in the vSphere Client. It is in the ESXi server advanced settings under DataMover. Figure 148 shows the setting in the vSphere Client.
By default, when the Full Copy primitive is supported, VMware informs the storage array to copy data in 4 MB chunks. The PowerMax, however, can accept larger sizes. The following two sections outline how to inform ESXi to send those larger sizes.
The default copy size can be incremented from 4 MB to a maximum value of 16 MB. This action should be done for all PowerMax arrays.
The following commands show how to query the current copy (or transfer) size and then how to alter it.
# esxcfg-advcfg -g /DataMover/MaxHWTransferSize
Value of MaxHWTransferSize is 4096
# esxcfg-advcfg -s 16384 /DataMover/MaxHWTransferSize
Value of MaxHWTransferSize is 16384
This change is per ESXi server and can only be done through the CLI (no UI interface) as in Figure 149:
Alternatively, vSphere PowerCLI can be used at the vCenter level to change the parameter on all hosts as in Figure 150.
In addition to maxing out the standard size to 16 MB, VMware is also capable of sending even larger sizes through a VAAI claim rule. These claim rules take precedence over the MaxHWTransferSize and can be used on the PowerMax.
Claim rules in general have always been used to implement VAAI on vSphere. VAAI is a plug-in claim rule. It says if a device is from a particular vendor, in this case a Dell PowerMax device, it should go through the VAAI filter. In other words, if VAAI can be used it is used.
Note: Various situations exist, detailed in this paper, where primitives like XCOPY are not used.
Each block storage device that a VAAI plug-in manages needs two claim rules:
Within the storage claim rules, VMware has three columns that control the behavior allowing larger XCOPY sizes. They are:
Figure 151 shows the output from vSphere with the columns and their default values.
By altering the rules and changing these three settings, you can adjust the max transfer size up to a maximum of 240 MB for the PowerMax. Though the columns show in both the Filter and VAAI claim rule classes, only the VAAI class must be changed. The new required settings are:
Changing the transfer size value is insufficient. If the transfer size is set, VMware requires that the array reported values be set to true. When use array reported values is set, VMware queries the array to get the largest transfer size when either:
Unfortunately, the PowerMax advertises a value higher than 240 MB. If an issue with the transfer size occurs (for whatever reason), VMware defaults to the MaxHWTransferSize. Therefore it is also important to set that to 16 MB. Also, to enable the PowerMax to accept up to 240 MB, the multiple segments value must be enabled. A single segment is limited to 30 MB. There are eight segments available. Therefore, when modifying the claim rules the size is set to 240 MB. Then set both other columns to true.
The process to change the claim rules entails:
Following this procedure, a reboot of the server is needed. The commands to run on the ESXi host as root are the following. They do not return a response. Sometimes VMware alters the exact syntax so use the esxcli help if necessary.
esxcli storage core claimrule remove --rule 65430 --claimrule-class=VAAI
esxcli storage core claimrule load --claimrule-class=VAAI
esxcli storage core claimrule add -r 65430 -t vendor -V EMC -M SYMMETRIX -P VMW_VAAIP_SYMM -c VAAI -a -s -m 240
To verify the changes are set before reboot, list the claim rules as in Figure 152:
esxcli storage core claimrule list --claimrule-class=VAAI
Once the reboot is complete, re-run the command to ensure that the changes appear.
You must remember that the new claim rule does not impact how VAAI functionality works. For instance, the following still hold true:
The maximum value is indeed a maximum. It is the largest extent VMware can send but does not guarantee all extents are of that size. VMware can send extents anywhere up to 240 MB depending on the fragmentation of the VMDKs.
VMware has begun the process of moving away from the custom vendor VAAI plug-ins (VMW_VAAIP_SYMM) enumerated in the previous section. To that end, VMware has always offered a generic plug-in for VAAI, named VMW_VAAIP_T10. This generic plug-in works the same way the custom plug-in does. The idea is to eventually deprecate all vendor custom plug-ins. The current implementation that is enumerated above using the custom plug-in is still supported. For new servers which do not already have the claim rules setup for PowerMax, Dell Technologies recommends using the new generic plug-in. VMware is eventually deprecating the Dell custom plug-in. The steps are similar to the custom plug-in and are as follows:
esxcli storage core claimrule remove --rule 65430 --claimrule-class=Filter
esxcli storage core claimrule remove --rule 65430 --claimrule-class=VAAI
esxcli storage core claimrule load --claimrule-class=Filter
esxcli storage core claimrule load --claimrule-class=VAAI
esxcli storage core claimrule add -r 914 -t vendor -V EMC -M SYMMETRIX -P VAAI_FILTER -c Filter
esxcli storage core claimrule add -r 914 -t vendor -V EMC -M SYMMETRIX -P VMW_VAAIP_T10 -c VAAI -a -s -m 240
esxcli storage core claimrule list --claimrule-class=VAAI
Note: For Storage vMotion operations, VMware uses a maximum of 64 MB for the extent size. This maximum is a VMware restriction and has nothing to do with the array. No change to the claim rules is required. Remember if VMware can use an extent size up to 240 MB it will, if not it uses something smaller. With Storage vMotion it does not exceed 64 MB.
One area where the increased extent size has made no difference in the past is with thin VMDKs as VMware always used 1 MB extents. In the current release, however, VMware tries to consolidate extents. When cloning it uses the largest extent that it can consolidate for each copy I/O (software or hardware). This new behavior has resulted in two benefits on the PowerMax. The first is obvious - any task requiring XCOPY on thin VMDKs is faster than on previous vSphere versions. The second benefit is unexpected - a clone of a thin VMDK now behaves like a thick VMDK in terms of further cloning. So, if you clone a thin VMDK VM and then use that clone as a template for further clones, those further clones are created at a speed almost equal to a thick VMDK VM clone. This situation happens whether that initial clone is created with or without XCOPY. The operation is essentially a defragmentation of the thin VMDK. If a thin VMDK VM is to be a template for other VMs, it must be cloned to a template rather than converted to a template. Doing so ensures that all additional deployments from the template benefit from the consolidation of extents.
Figure 154 and Figure 155 demonstrate the effectiveness of using claim rules for XCOPY when cloning 100 GB of data.
For more detail and additional test results for XCOPY, see Using VMware Storage APIs for Array Integration with Dell PowerMax.
Note: The terms source and target in relation to XCOPY always indicate datastores on the same array.