UPDATE: The issue outlined below with code level R32 has now been fixed. This issue is addressed in VNX OE for Block 05.32.000.5.209 (Inyo MR1 SP3). This was covered in EMC Technical Advisory (ETA) 172796 and KB article 172796.
There is a known latency issue with the VMware XCOPY primitive when used with EMC VNX Operating Environment Release 32. The problem is detailed in EMC KB90433 – please read this before proceeding with any changes.
“EMC are developing a fix for this issue for the next release of OE R32 currently scheduled for Q4 2013”
The following operations may trigger the bug:
Deploying Templates with VMware
Any ESX operation which is used to copy or migrate data within the same physical array
Until the fix is released it would be adivisable to disable the XCOPY primitive. The other VAAI Primitives are functioning correctly.
Please refer to VMware KB http://kb.vmware.com/kb/1033665 on details of how to disable the VAAI Primitives.
On ESX 5.x hosts, to determine if VAAI XCOPY is enabled, run the following command and check if Int Value is set to 1 (enabled):
# esxcli system settings advanced list -o /DataMover/HardwareAcceleratedMove
Expected output for XCOPY ENABLED:
Disabling VAAI using the vSphere Client:
1.Click the Configuration tab.
2.Under Software, click Advanced Settings.
4.Change the DataMover.HardwareAcceleratedMove setting to 0.
HardwareAcceleratedLocking Atomic Test & Set (ATS), which is used during creation of files on the VMFS volume
HardwareAcceleratedMove Clone Blocks/Full Copy/XCOPY, which is used to copy data
HardwareAcceleratedInit Zero Blocks/Write Same, which is used to zero-out disk regions
esxcli system settings advanced list –option=/VMFS3/HardwareAcceleratedLocking
esxcli system settings advanced list –option=/DataMover/HardwareAcceleratedMove
esxcli system settings advanced list –option=/DataMover/HardwareAcceleratedInit