Dynamox,  yes, if you changed the policy the SG was associated with to exclude EFD, FAST VP would slowly move data out of EFD to become compliant with the policy.  The keyword here, though, is slowly. And I mean slooooooooooowly.  Compliance movement requests generated by FAST VP are limited to a maximum of 10GB, based on an FRR of 1.  If the FRR is something other than 1 then divide 10GB by that number to get the new max size of a compliance request. eg at the default FRR of 5, the max compliance request size is 2GB.  Compliance requests are only generated approximately once every 10-15 minutes.  If you're only moving 2GB every 10 minutes it's going to take a while to move, potentially, TBs of data.  The VLUN migration Paul suggested is the best and fastest course of action in this case. However, the -src_pool option requires the array to be running 5876 code, so hopefully that is the case.  PS the max movement request size tied to the FRR only applies to compliance movements, it does not apply to performance related movements.
We recently migrated over to a VMAX 10K, and turned on FASTVP for our Primary Healthcare application here. It quickly took over all of the EFD disk that FAST had allocated to other applications. Unfortunately, due to the way the application stores and accesses data, as well as the typical life cycle of Patient data in a hospital, FAST doesn't seem to have made any noticeable change in performance.   So, I'd like to pull back the EFD disk that has been allocated to this Storage Group. I was told that if I just disassociate the Storage Group with the FAST policy, the data that's currently on EFD disk, will just stay on the EFD disk. Is that correct? If so, how can I get all of the data from the Storage Group back to just FC disk?  Thank you
How can I pull back my EFD allocated through FASTVP?