Itzikr's Blog

H

lately, I had to deal with a customer case who thought that one of the VAAI Primitives isn’t working so I decided to put some more light on the issue.

Chad already covered this in length on his blog with the following posts:

http://virtualgeek.typepad.com/virtual_geek/2011/07/3-pieces-of-bad-news-and-a-deep-dive-into-apd.html and http://virtualgeek.typepad.com/virtual_geek/2011/09/vnx-and-vnxe-updates-and-vaai-hotfixes.html

but there were some updates / correction since this blog was written so I here they are, as always, please make sure you receive the most up to date information from your EMC rep as things tend to change over time.. (this post was written in Feb 2012)

VMAX

vSphere 4.1

we support the 3 VAAI Primitives:

– Hardware-accelerated Full Copy

– Hardware-accelerated Block Zero

-Hardware-assisted locking

caveat for the XCOPY primitive as taken from the publicly available doc since June 2011,

note that this document will explain in length the impact of VAAI when using a VMAX array so it’s a very good document (and not too long) to read

Basically,

“XCOPY on meta devices lays out the protection bitmaps in the host based cylinder format. All legacy sessions lay out the bitmaps in internal member cylinder format. As a result, the two session types cannot coexist. SRDF uses a different mechanism so this compatibility issue does not apply”

– Environments running Enginuity 5875.135.91, 5875.139.93 or 5875.198.148 and using VAAI should upgrade to Target version Enginuity 5875.231.172. Contact your EMC Service Representative and quote solution ID emc263675

This issue is resolved in ESX/ESXi 4.1 Patch 03:

– VMware ESX 4.1, Patch Release ESX410-201107001
For more information, see VMware ESX 4.1, Patch Release ESX410-201107001 (2000612)2000755

– VMware ESXi 4.1, Patch Release ESXi410-201107001
For more information, see VMware ESXi 4.1, Patch Release ESXi410-201107001 (2000613).

– VMware ESXi 5.0, Patch Release ESXi500-201109401-BG
For more information, see VMware ESXi 5.0 Patch ESXi500-201109401-BG: Updates esx-base (1027808).

Roadmap – There is no planning to “fix” this and the eng department never received such a request so if the client think it’s a must you can fill a feature request.

vSphere 5

we support the other primitive (stun and resume) but the “space reclaim”  one has been identified in VMware as not working so VMware decided to withdraw the support and ask customers to disable it on the ESX hosts. (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007427 )

The VMAX array already rejects it so there is no need to reject it on the hosts

VNX

vSphere 4.1

we support the 3 primitives in all the cases but the XCOPY one may work faster by using the ESX copy (depends on the customer environment workload) so we recommend customers to either:

1. leave as is if they are happy with the performance.

1. Disable Hardware-accelerated Full Copy on the hosts if the VNX copy is working slower than the ESX one..

2. Apply for a special VNX enabler that will bring the VNX XCOPY to the same speed as the ESX one (as EMC customer support)

the customer must be running a minimum version of VNX OE for Block v05.31.000.5.502

you can read more about the VAAI coverage in vSphere 4.1 using the EMC VNX systems clicking the link below:

Roadmap – A VNX future release will contain this enabler as an integral part of the release (among other very important VAAI enhancements..)

vSphere 5

We support the NFS VAAI via a plugin that have to be installed on the ESXi hosts, you can read more about it, clicking on the image below

We support the other primitive but the “space reclaim”  one has been identified in VMware as not working so VMware decided to withdraw the support and ask customers to disable it on the ESX hosts.

The VNX array doesn’t  rejects it so there IS a need to reject it on the hosts

RECOVERPOINT

General notes:

– Support and best practices for RecoverPoint are on top of the support and best practices given for the arrays themselves.

– Roadmap : Focus is made on the array splitters, to support the rest of the VAAI commands in future versions.

vSphere 4.1

With the VNX/CX splitter, we support all commands:

– HW Assist Locking since RecoverPoint 3.3 SP1 and R30 (4.30.000.5.509 and up)

– WriteSame since RecoverPoint 3.4, R31

– XCOPY since RecoverPoint 3.4, R31

With the Symmetrix splitter (on VMAXe), we support

– HW Assist locking since RecoverPoint 3.4 SP1 and Rhine microcode

Intelligent fabric splitters (Brocade and Cisco) reject all VAAI commands (since Cisco SSI 4.2.3k and 5.0.4j; RecoverPoint 3.4).

vSphere 5

We support the thin provisioning “Stun” commands with the VNX/CX and Symmetrix splitters, since RecoverPoint 3.4 SP1.

CLARiiON

vSphere 4.1

all the 3 VAAI API’s are supported.

vSphere 5 / 5 update 1

we do not support any of the API’s as they didn’t pass the speed enhancements required for VAAI, technically speaking, they will work. we are working with VMware to try and certify the ATS API as supported.

27/03/2012 Update:

VMware have released vSphere 5.0 update 1 and one of it’s features is the UNMAP also known as “Space Reclaim”, it’s a manual step.

here’s the current support matrix for our arrays in regards to this API

VNX – YES

VMAX – NO