While I agree it was coincidental and possibly related (enabling SP read cache), is it possible instead that the following KB article is related?  This was only recently fixed but was enough of an issue that until the array could be upgraded we suggested disabling it on the ESX/ESXi hosts in the meantime.  emc313487: "Extended Copy (XCOPY) VAAI Primitive not behaving as expected with VNX OE Release 32"  This assumes of course that they are running VNX OE for Block v32 (up to version 05.32.000.5.201 where it is now fixed) and the environment is configured for VAAI (ESX/ESXi v4.1+, failover mode 4, Datamover.HardwareAcceleratedMove = 1, etc.).
All,  I have a customer who has two VNX5300's and are using RecoverPoint for DR. FASTCache is installed on the production array and everything has been working fine for 4 or 5 months.  EMC Support where involved in helping them resolve an issue and noted that Read Cache was disabled on the production and DR arrays, the support person recommend having read cache enabled.  This was done, it was enabled and set at 400MB as per article emc267304. The customer then tried to do some VMotion of servers from one datastore to another which they have done many times and performance bombed. It took 8hrs to VMotion over 1 150GB VM. Recoverpoint also threw up errors, a mix of Event ID 4000, 4001, 4008 and 5030  The only change made in the environment was the enabling of read cache.I have since returned the cache setting to what they where and the customer is going to try a VMotion again.  My question is, would the change in cache be enough to cause this. I read article emc277689 which seemed to say that read cache should be enabled even after an enabler had disabled it.  I am interested in hearing your views and if anyone has had this issue before.  TIA  Ken
FastCache and Read Cache