Skip to main content

SVM data mobility overview

Contributors netapp-lenida netapp-ahibbard netapp-aherbin netapp-dbagwell netapp-mwallis
PDFs

Beginning with ONTAP 9.10.1, cluster administrators can non-disruptively relocate an SVM from a source cluster to a destination cluster to manage capacity and load balancing, or to enable equipment upgrades or data center consolidations by using the ONTAP CLI.

This non-disruptive SVM relocation capability is supported on AFF platforms in ONTAP 9.10.1 and 9.11.1. Beginning with ONTAP 9.12.1, this capability is supported on both FAS and AFF platforms and on hybrid aggregates.

The SVM’s name and UUID remain unchanged after migration, as well as the data LIF name, IP address, and object names, such as the volume name. The UUID of the objects in the SVM will be different.

SVM migration workflow

The diagram depicts the typical workflow for an SVM migration. You start an SVM migration from the destination cluster. You can monitor the migration from either the source or the destination. You can perform a manual cutover or an automatic cutover. An automatic cutover is performed by default.

Workflow of SVM migration. This summarizes the steps that follow it.

SVM migration platform support

Controller family

ONTAP versions supported

AFF A-series

ONTAP 9.10.1 and later

AFF C-series

ONTAP 9.12.1 patch 4 and later

FAS

ONTAP 9.12.1 and later
Note When migrating from an AFF cluster to a FAS cluster with hybrid aggregates, auto volume placement will attempt to perform a like to like aggregate match. For example, if the source cluster has 60 volumes, the volume placement will try to find an AFF aggregate on the destination to place the volumes. When there is not sufficient space on the AFF aggregates, the volumes will be placed on aggregates with non-flash disks.

Scalability support by ONTAP version

ONTAP version

HA pairs in source and destination

ONTAP 9.14.1

12

ONTAP 9.13.1

6

ONTAP 9.11.1

3

ONTAP 9.10.1

1

Network infrastructure performance requirements for TCP round trip time (RTT) between the source and the destination cluster

Depending on the ONTAP version installed on the cluster, the network connecting the source and destination clusters must have a maximum round trip time as indicated:

ONTAP version

Maximum RTT

ONTAP 9.12.1 and later

10ms

ONTAP 9.11.1 and earlier

2ms

Maximum supported volumes per SVM

Source

Destination

ONTAP 9.14.1

ONTAP 9.13.1

ONTAP 9.12.1

ONTAP 9.11.1 and earlier

AFF

AFF

400

200

100

100

FAS

FAS

80

80

80

N/A

FAS

AFF

80

80

80

N/A

AFF

FAS

80

80

80

N/A

Prerequisites

Before initiating an SVM migration, you must meet the following prerequisites:

  • You must be a cluster administrator.

  • The source and destination clusters must be peered to each other.

  • The source and destination clusters must have the SnapMirror synchronous license installed. This license is included with ONTAP One.

  • All nodes in the source cluster must be running ONTAP 9.10.1 or later. For specific ONTAP array controller support, see Hardware Universe.

  • All nodes in the source cluster must be running the same ONTAP version.

  • All nodes in the destination cluster must be running the same ONTAP version.

  • The destination cluster ONTAP version must be at the same or no more than two major newer versions as the source cluster.

  • The source and destination clusters must support the same IP subnet for data LIF access.

  • The source SVM must contain fewer than the maximum number of supported data volumes for the release.

  • Sufficient space for volume placement must be available on the destination

  • Onboard Key Manager must be configured on the destination if the source SVM has encrypted volumes

Best practice

When performing an SVM migration, it is a best practice to leave 30% CPU headroom on both the source cluster and the destination cluster to enable the CPU workload to execute.

SVM operations

You should check for operations that can conflict with an SVM migration:

  • No failover operations are in progress

  • WAFLIRON cannot be running

  • Fingerprint is not in progress

  • Vol move, rehost, clone, create, convert or analytics are not running

Supported and unsupported features

The table indicates the ONTAP features supported by SVM data mobility and the ONTAP releases in which support is available.

For information about ONTAP version interoperability between a source and destination in an SVM migration, see Compatible ONTAP versions for SnapMirror relationships.

Feature

Release first supported

Comments

Autonomous Ransomware Protection

ONTAP 9.12.1

Cloud Volumes ONTAP

Not supported

External key manager

ONTAP 9.11.1

FabricPool

ONTAP 9.11.1

SVM migration is supported with volumes on FabricPools for the following platforms:

  • Azure NetApp Files platform. All tiering policies are supported (snapshot-only, auto, all, and none).

Fanout relationship (the migrating source has a SnapMirror source volume with more than one destination)

ONTAP 9.11.1

FC SAN

Not supported

Flash Pool

ONTAP 9.12.1

FlexCache volumes

Not supported

FlexGroup

Not supported

IPsec policies

Not supported

IPv6 LIFs

Not supported

iSCSI SAN

Not supported

Job schedule replication

ONTAP 9.11.1

In ONTAP 9.10.1, job schedules are not replicated during migration and must be manually created on the destination. Beginning with ONTAP 9.11.1, job schedules used by the source are replicated automatically during migration.

Load-sharing mirrors

Not supported

MetroCluster SVMs

ONTAP 9.16.1

You can migrate an SVM from either a non-MetroCluster HA pair into a MetroCluster configuration or from a MetroCluster configuration to a non-MetroCluster HA pair. You cannot migrate an SVM from one MetroCluster configuration to another MetroCluster configuration.

[NOTE] SVM migrate does not support MetroCluster SVM migration in releases earlier than ONTAP 9.16.1. You might be able to use SnapMirror asynchronous replication to migrate an SVM in a MetroCluster configuration. You should be aware that using SnapMirror asynchronous for migrating an SVM in a MetroCluster configuration is disruptive migration method.

NetApp Aggregate Encryption (NAE)

Not supported

Migration is not supported for any endpoint that uses NAE.

NDMP configurations

Not supported

NetApp Volume Encryption (NVE)

ONTAP 9.10.1

NFS and SMB audit logs

ONTAP 9.13.1
Note

For on-premises SVM migration with audit enabled, you should disable audit on the source SVM and then perform the migration.

Before SVM migration:

NFS v3, NFS v4.1, and NFS v4.2

ONTAP 9.10.1

NFS v4.0

ONTAP 9.12.1

NFSv4.1 with pNFS

ONTAP 9.14.1

NVMe over Fabric

Not supported

Onboard key manager (OKM) with Common Criteria mode enabled on source cluster

Not supported

Qtrees

ONTAP 9.14.1

Quotas

ONTAP 9.14.1

S3

Not supported

SMB protocol

ONTAP 9.12.1

SMB migrations are disruptive and require a client refresh post migration.

SnapMirror cloud relationships

ONTAP 9.12.1

Beginning with ONTAP 9.12.1, when you migrate an on-premises SVM with SnapMirror cloud relationships, the destination cluster must have the SnapMirror cloud license installed, and it must have enough capacity available to support moving the capacity in the volumes that are being mirrored to the cloud.

SnapMirror asynchronous destination

ONTAP 9.12.1

SnapMirror asynchronous source

ONTAP 9.11.1

  • Transfers can continue as normal on FlexVol SnapMirror relationships during most of the migration.

  • Any ongoing transfers are canceled during cutover and new transfers fail during cutover and they cannot be restarted until the migration completes.

  • Scheduled transfers that were canceled or missed during the migration are not automatically started after the migration completes.

    Note

    When a SnapMirror source is migrated, ONTAP does not prevent deletion of the volume after migration until the SnapMirror update takes place. This happens because SnapMirror-related information for migrated SnapMirror source volumes is available only after migration is complete, and after the first update takes place.

SMTape settings

Not supported

SnapLock

Not supported

SnapMirror active sync

Not supported

SnapMirror SVM peer relationships

ONTAP 9.12.1

SnapMirror SVM disaster recovery

Not supported

SnapMirror synchronous

Not supported

Snapshots

ONTAP 9.10.1

Tamperproof snapshot locking

ONTAP 9.14.1

Tamperproof snapshot locking is not equivalent to SnapLock. SnapLock Enterprise and SnapLock Compliance remain unsupported.

Virtual IP LIFs/BGP

Not supported

Virtual Storage Console 7.0 and later

Not supported

Volume clones

Not supported

vStorage

Not supported

Migration is not allowed when vStorage is enabled. To perform a migration, disable the vStorage option, and then reenable it after migration is completed.

Supported operations during migration

The following table indicates volume operations supported within the migrating SVM based on migration state:

Volume operation

SVM migration state

In progress

Paused

Cutover

Create

Not allowed

Allowed

Not supported

Delete

Not allowed

Allowed

Not supported

File System Analytics disable

Allowed

Allowed

Not supported

File System Analytics enable

Not allowed

Allowed

Not supported

Modify

Allowed

Allowed

Not supported

Offline/Online

Not allowed

Allowed

Not supported

Move/rehost

Not allowed

Allowed

Not supported

Qtree create/modify

Not allowed

Allowed

Not supported

Quota create/modify

Not allowed

Allowed

Not supported

Rename

Not allowed

Allowed

Not supported

Resize

Allowed

Allowed

Not supported

Restrict

Not allowed

Allowed

Not supported

Snapshot attributes modify

Allowed

Allowed

Not supported

Snapshot autodelete modify

Allowed

Allowed

Not supported

Snapshot create

Allowed

Allowed

Not supported

Snapshot delete

Allowed

Allowed

Not supported

Restore file from snapshot

Allowed

Allowed

Not supported