Highlighted
chrisfraser11
1 Nickel

XCOPY and VAAI issues with FLARE 05.32.000.5.207

Hi folks,

I'm facing an issue with XCOPY performance on FLARE 05.32.000.5.207 that has basically ground a customer migration to a halt.

As I understand it, the issue should be resolved with the upcoming Inyo SP3 MR1 and possibly an interim hotfix.

Has anyone come up with a good workaround so that we can get this project moving? Svmotion performance is consistently unacceptable without VAAI, but the performance with VAAI is very inconsistent and it's preventing the project from moving forward.

Thanks

Labels (2)
Tags (3)
2 Replies
kubernetes
1 Copper

Re: XCOPY and VAAI issues with FLARE 05.32.000.5.207

Hi Chris,

To alleviate the issue you have to disable one of primitives of VAAI: XCOPY (VAAI Full Copy and HardwareAcceleratedMove are names of the same).

To disable this simple run command from esxi host:

# esxcli system settings advanced set -o /DataMover/HardwareAcceleratedMove -i 0

I believe that disabling XCOPY we still use fs3dm datamover on VMware host instead of fsdm legacy datamover and that data does not need to traverse the entire storage stack.

We tested that and saw that performance of svMotion was improved than with XCOPY enabled.

Regards,

KB

0 Kudos
christopher_ime
4 Beryllium

Re: XCOPY and VAAI issues with FLARE 05.32.000.5.207

Chris Fraser wrote:

Hi folks,

I'm facing an issue with XCOPY performance on FLARE 05.32.000.5.207 that has basically ground a customer migration to a halt.

Chris,

Just curious, when you mention "migration" are you copying from one array to another?  Or is the svMotion from one datastore (LUN) to another datastore (LUN) each contained within the same VNX?  Reason I ask is that in the former scenario, XCOPY wouldn't even be used.

Apologies in advance for asking.  I debated whether or not to ask. 

0 Kudos