Vol move questions

[dmarkham]

Have a couple of questions about vol moves.  Customer has roughly 34 volumes to move from an A200 to an new A250 in the cluster.   They would like to start baselining all of the volume moves with deferred cutovers.  The cutovers will be manually triggered during their maintenance window in a couple of weeks.

1) Does the vol move start with the "cutover-action wait" parameter just do a one time baseline of the data and then when you manually trigger the cutover it does an incremental copy of all changes since the baseline or does the job do some sort of incremental changes periodically between the baseline and the manual cutover?

2) It looks like there is a parameter on vol moves which restricts you to 8 concurrent vol moves.   It looks like we can increase that option.   Is it ok to bump it up for this customer to allow more than 8 vol moves to be sitting in a cutover deferred state? We would still not have more than 4-8 concurrent baselines going at one time but we would want to be able to have all 34 volumes in a cutover deferred state at the end of the process to prep for cutting them all over during the maintenance window and avoid having to baseline the larger volumes during that window.

Thanks...

Dean

[Sergey_Osipov]

1) underlined the answer

https://docs.netapp.com/us-en/ontap-cli-9131/volume-move-start.html#parameters

[-cutover-action {abort_on_failure|defer_on_failure|force|wait|retry_on_failure}] - Action for Cutover (privilege: advanced)

Specifies the action to be taken for cutover. If the effective cluster version is Data ONTAP 8.3 and later, the default is retry_on_failure ; otherwise the default is defer_on_failure . If the abort_on_failure action is specified, the job tries to cutover until cutover attempts are exhausted. If it fails to cutover, it cleans up and ends the operation. If the defer_on_failure action is specified, the job tries to cutover until the cutover attempts are exhausted. If it fails to cutover, it moves into the "cutover deferred" state. The volume move job waits to issue a volume move trigger-cutover command to restart the cutover process. If the force action is specified, the job tries to cutover until the cutover attempts are exhausted and forces the cutover at the expense of disrupting the clients. If the wait action is specified, when the job hits the decision point, it does not go into cutover automatically, instead it waits to issue a volume move trigger-cutover command as the signal to try the cutover. Once cutover is manually triggered, the cutover action changes to defer_on_failure . If the retry_on_failure action is specified, the job retries to cutover indefinitely and it never enters a "hard-deferred" state. After exhausting cutover attempts, the move job waits one hour before trying to cutover again. Issue a volume move trigger-cutover command at any time to restart the cutover process.

2) Though it is possible to change the volume governor limit, it is not recommended by NetApp Engineering to do so.

[dmarkham]

Thanks Sergey.   As to the first part of your answer, I was aware the the cutover wait parameter did delay the cutover to be a manual process.  My question was really whether when you specifying this parameter does the volume move process continue to update the destination volume with changes until the cutover is manually triggered so that the actual changes that need to be transferred during the cutover are smaller.  I have heard from another source that this was the case and was trying to confirm.

[Sergey_Osipov]

Sorry didn't understand your question properly

|wait| -

After the baseline transfer, vol move remains in the iterative phase, periodically replicating the source to target volume. Cutover is not attempted until the administrator manually triggers it using the vol move trigger-cutover command. Then the cutover is attempted the next time a cutover decision point is reached. This option is particularly useful for very active volumes for which cutover within the required interval may be difficult to achieve. The bulk of the replication can proceed concurrently with user access and the cluster administrator can wait for a known less busy time to trigger the cutover. The cutover can even be deferred to a planned maintenance window.