Unsolved
This post is more than 5 years old
5 Practitioner
•
274.2K Posts
1
1474
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
kubernetes
1 Message
0
September 22nd, 2013 05:00
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
christopher_ime
2K Posts
0
September 22nd, 2013 21:00
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.