Volume move jobs can run concurrently on the same node or different nodes in a cluster. In general, all jobs serviced by the same controller share the available background resources, which are also shared with other traffic such as SnapMirror. Vol move replication is automatically and transparently throttled during the initial transfer so as not to increase client latency. Therefore, kicking off many volume move jobs in parallel on a single node may not result in the vol moves completing any faster than if multiple batches of volume move jobs were started sequentially.
In Data ONTAP 8.3, an automatic and transparent governor process queues and regulates vol move jobs so that an administrator can initiate as many individual jobs as required. Counters are kept of the number of references to the aggregates owned by each node in all the current vol move jobs, whether as a source or target aggregate. If 8 or fewer aggregate references for a node are involved in the initiated vol move jobs, all jobs will execute uninterrupted. If additional references are made to aggregates on that node in subsequent vol move jobs, these will wait in the setup phase after creating the target volume until one of the executing jobs completes.
the max of simultaneous volume moves in 8.2 was 16. But concurrent reads (on SAS/SATA disk particularly) could impact severly your 3250. So, moving lot of volumes simultaneously can last long (more than your maintenance window).
Even if you move one by one your volume (max 16) with manual cutover, periodically, any changes made to the source volume are replicated to the destination aggregate, with possible impact on performances.
So, you should move first your volumes with the biggest workload, cut over them during maintenance window if necessary, migrate the LIFs to the 8040, and move other volumes.
It would be really interesting to know what the performance impact for a volume move is.
I have started a volume move on a FAS2552 from Aggr1 to Aggr2 with each about 100TB space. The volume I'm moving is 20TB big.
On another volume on aggr2 there is a share. That share has a folder with 500 small files. There's a process with these files replacing the files then unpacking, modifying, packing it back... this process usually takes 15-20 minutes... and runs every hour... now since I started the vol move it's taking 1h 20 minutes... so it's four times the time it has consumed before the vol move. I can see with statistics show-periodic that the CPU (95% and higher) is pretty high on the controller node that owns the disks of Aggr2. Now I'm not saying that it's ONLY the vol move but clearly the move process has an impact on the performance - can anyone point me to any literature that is discussing this?