HPE Storage Users Group

Hello all.

We have an ESX farm attached to two different T800s, since upgrading and enabling T10 features, the ESX guy is discovering random vmotion fails when DRS tries to move a vmdk from one data store on 1 3par to a datastore on the other... I suspect its tying to use T10 offloading and failining.

Whats the suggested method to teach ESX to use host based copies when going from X to Y, but use T10 for X to X copies, or Y to Y copies?

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

This may also apply:

http://emulex.force.com/knowledgebase/a ... egredation

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

I'm guessing you are talking about hardware acceleration and the vaai copy, rather than T10, as T10 Is just for reclaiming space.

There are a lot of conditions for which need to be true for the copy to work using vaai, however if it fails to validate it should just fall back to the old skool method and use SCSI-2 reservations.

Worth checking these

VAAI hardware offload cannot be used when:
The source and destination VMFS volumes have different block sizes
The source file type is RDM and the destination file type is non-RDM (regular file)
The source VMDK type is eagerzeroedthick and the destination VMDK type is thin
The source or destination VMDK is any kind of sparse or hosted format
Cloning a virtual machine that has snapshots because this process involves consolidating the snapshots into the virtual disks of the target virtual machine.
The logical address and/or transfer length in the requested operation is not aligned to the minimum alignment required by the storage device (all datastores created with the vSphere Client are aligned automatically)
The VMFS datastore has multiple LUNs/extents spread across different arrays
Note:
Hardware cloning between arrays (even if within the same VMFS datastore) does not work.
For information on supportability with Horizon View, refer to KB Article View Composer API for Array Integration (VCAI) support in VMware Horizon View (2061611).

So if it tries and fails it will fall back anyway, and it shouldn't have any issue deterring they are different arrays.

Take a look at this kb too

http://kb.vmware.com/selfservice/micros ... Id=1021976

Actually T10 is the ANSI committee in charge of the SCSI standards and all of the storage related features in vmware are just implementations of various T10 standards which is why hyper-v also implements them.

David, you seem confused on the VAAI <-> T10 relationship.

All VAAI primitives are now standard T10 opcodes.
There is no requirement for XCOPY to work,
other than the array to support it.

When you talk about fallback to SCSI reservations, that is in releation to ATS.

Richard, XCOPY does not work between arrays.
There must be something else wrong, start looking in the vmkernel log.

We think its the Emulex Driver, we're deploying new drivers (8.2.4.157.70) to dev soon. They are the latest on the HP support matrix.

Symptoms
A performance issue may be observed when VAAI is enabled. In some cases the Target will return a SCSI CHECK_CONDITION (0x2). This CHECK_CONDITION will then cause the driver to return HOST_BUS_BUSY to the SCSI layer. This could result in an IO failure storm. The indication will be when Cmd’s are failed with status 0x2.

Cause
The exact failure condition will happen only when VAAI is enabled with a driver version 8.2.x.141.50 or later. These driver versions checked to ensure the transfer was done successfully on reads and writes. The user will notice a performance decrease on these operations and potentially an IO failure storm.

Solution
Install v8.2.4.156.69 or later to obtain the fix.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

Did you find the clues from the vmkernel log, or did HP find it?

For what it's worth I have started making my own async driver package with the most used drivers as a baseline.
The reason is twofold:

1.

If you install using the OEM install CD, the vendor updated drivers will not be automatically updated if you are using update manager to deploy OS patches.
Newer inbox drivers will NOT update the OEM drivers, even with a higher version number.

2.

Certification matrix'es are less and less worth these days.
Getting lots of issues even if sticking to strict HCL listings.
See other thread about general IT SW quality deteriorating over the last years.

I've found that creating own baseline that is quite new and semi frequently updated, seems to be the best cure.