ONTAP Volume Move: Cutover and Troubleshooting

Volume move is the ONTAP feature that lets you fix a capacity imbalance, retire a node or re-tier data without taking an application offline. It copies the volume to a new aggregate (possibly on another node in the same SVM), does a short cutover, then cleans up the source. The copy phase is slow but harmless; the cutover phase happens in seconds and is where things go wrong. This guide covers the pre-checks, the commands, the cutover parameters that are easy to miss, and how to recover when a move fails.

When Volume Move Is the Right Tool

• An aggregate is nearly full while another node has capacity — moving a few volumes beats buying disk.
• A node is being replaced or decommissioned and its volumes must relocate.
• Data needs re-tiering: move a hot volume to an SSD/flash aggregate without downtime.

Volume move works on FlexVol volumes and keeps the volume in the same SVM; it is not a replacement for SnapMirror when the destination is a different cluster.

Before You Start

cluster1::> volume move target-aggr show -vserver vs2 -volume user_max
Aggregate Name   Available Size   Storage Type
--------------   --------------   ------------
aggr2            467.9GB          hdd
node12a_aggr3    10.34GB          hdd
node12a_aggr2    10.36GB          hdd

cluster1::> aggr show -fields size,availsize,node
cluster1::> volume show -vserver vs2 -volume user_max -fields size,aggregate

Confirm the target aggregate's available size exceeds the volume size — including any snapshot growth during the copy, because new writes keep landing on the source. Also check:

• 8K adaptive compression: moving such a volume to a platform with dedicated offload storage efficiency changes where space is saved. The active file system must be larger, so increase the volume size before the move to avoid running out of space mid-copy.
• SnapMirror relationships: a data protection mirror relationship must be initialised (snapmirror initialize) before its volume can be moved.
• Privilege level: volume move is a cluster administrator task; the cutover tuning parameters additionally require advanced privilege.

Starting and Watching a Move

cluster1::> volume move start -vserver vs2 -volume user_max -destination-aggregate aggr2

# progress, in the documented fields: state, phase, percentage complete, cutover window
cluster1::> volume move show -vserver vs2
cluster1::> volume move show -vserver vs2 -instance        # detailed, per-phase view

# pause / resume / abort while in the copy phase
cluster1::> volume move pause -vserver vs2 -volume user_max
cluster1::> volume move resume -vserver vs2 -volume user_max

# force the cutover if you cannot wait for the automated one
cluster1::> volume move trigger-cutover -vserver vs2 -volume user_max

The copy phase can take hours on a large volume — that is expected and non-disruptive. volume move show reports the cutover window and how far the replication has progressed; watch it rather than polling the job status blindly.

The Cutover: Short, But Configured in Advance

By default, if the cutover does not complete within 30 seconds it retries. Two advanced-privilege parameters change that behaviour, and both must be decided before the move matters:

cluster1::> volume move start -vserver vs2 -volume user_max \
            -destination-aggregate aggr2 -cutover-window 120 -cutover-action defer_check_fail

Why clients matter: during cutover, briefly interrupted I/O is expected, but sessions that hold the volume busy (SQL log files, a backup job, an open snapshot dependency) can stretch the cutover. Quiet heavy I/O — backups, antivirus scans, replication jobs — before the window, and issue volume move trigger-cutover manually if you are in a change window and want control over the moment.

After the Move

cluster1::> volume show -vserver vs2 -volume user_max -fields aggregate,size,used
cluster1::> volume move show -vserver vs2            # no entries = clean
cluster1::> snapmirror show -fields state           # relationships healthy again?
cluster1::> aggr show -fields availsize              # source aggregate reclaimed space

Also update your documentation and any monitoring that pinned the volume to an aggregate or node, and re-verify performance: a volume moved to a busier node can look like an application regression even though the move succeeded.

When a Move Fails

Operational Practice

1. Always run volume move target-aggr show first — never guess capacity.
2. Set -cutover-window and -cutover-action deliberately for volumes with long-lived I/O, and document the choice.
3. Move during a quiet window; a cutover measured in seconds beats one that retries for ten minutes.
4. Re-verify SnapMirror, monitoring and performance baselines after every move.

相关阅读：NetApp ONTAP SnapMirror 配置（CLI）、ONTAP aggregate 空间用量排查 以及 ONTAP FlexGroup 创建与扩容。

原文链接：NetApp ONTAP documentation - Move an ONTAP volume