ONTAP 9.14

to Japanese version

SVM data mobility overview

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 ETERNUS AX series in ONTAP 9.10.1 and 9.11.1. Beginning with ONTAP 9.12.1, this capability is supported on both ETERNUS HX series and ETERNUS AX series 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.

SVM migration workflow

SVM migration platform support

Controller family

ONTAP versions supported

ETERNUS AX series

ONTAP 9.10.1 and later

ETERNUS AC series

ONTAP 9.12.1 patch 4 and later

ETERNUS HX series

ONTAP 9.12.1 and later

When migrating from an ETERNUS AX cluster to a ETERNUS HX 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 ETERNUS AX aggregate on the destination to place the volumes. When there is not sufficient space on the ETERNUS AX 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

ETERNUS AX series

ETERNUS AX series

400

200

100

100

ETERNUS HX series

ETERNUS HX series

80

80

80

N/A

ETERNUS HX series

ETERNUS AX series

80

80

80

N/A

ETERNUS AX series

ETERNUS HX series

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.

  • All nodes in the source cluster must be running ONTAP 9.10.1 or later.

  • 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 must be at the same or no more than two major newer effective cluster versions (ECV) 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

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.

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

Learn more about FabricPool support.

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

iSCI 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

Not supported

Although SVM migrate does not support MetroCluster SVM migration, you might be able to use SnapMirror Asynchronous replication to migrate an SVM in a MetroCluster configuration. You should be aware that the process described for migrating an SVM in a MetroCluster configuration is not a non-disruptive method.

Aggregate Encryption (AE)

Not supported

Migration is not supported from an unencrypted source to an encrypted destination.

NDMP configurations

Not supported

Volume Encryption (VE)

ONTAP 9.10.1

NFS and SMB audit logs

ONTAP 9.13.1

Before SVM migration:

  • Audit log redirect must be enabled on the destination cluster.

  • The audit log destination path from the source SVM must be created on the destination cluster.

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 asynchronous copy-to-cloud relationships

ONTAP 9.12.1

Beginning with ONTAP 9.12.1, when you migrate an SVM with SnapMirror Copy to Cloud relationships, the destination cluster must have the copy-to-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.

    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 Business Continuity

Not supported

SnapMirror SVM peer relationships

ONTAP 9.12.1

SnapMirror SVM disaster recovery

Not supported

SnapMirror Synchronous

Not supported

Snapshot copy

ONTAP 9.10.1

Tamperproof Snapshot copy locking

ONTAP 9.14.1

Tamperproof Snapshot copy locking is not equivalent to SnapLock. SnapLock remains unsupported.

Virtual IP LIFs/BGP

Not supported

Virtual Storage Console 7.0 and later

Not supported

VSC is part of the ONTAP Tools for VMware vSphere virtual appliance beginning with VSC 7.0.

Volume clones

Not supported

vStorage

Not supported

FabricPool support

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

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

  • On-premises platform. Only the "none" volume tiering policy is supported.

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 copy attributes modify

Allowed

Allowed

Not supported

Snapshot copy autodelete modify

Allowed

Allowed

Not supported

Snapshot copy create

Allowed

Allowed

Not supported

Snapshot copy delete

Allowed

Allowed

Not supported

Restore file from Snapshot copy

Allowed

Allowed

Not supported

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

File operation

SVM migration state

In progress

Paused

Cutover

Asynchronous delete

Not allowed

Not allowed

Not supported

Clone create/delete/split

Allowed

Allowed

Not supported

Copy modify/destroy

Not allowed

Not allowed

Not supported

Move

Not allowed

Not allowed

Not supported

Reserve

Allowed

Allowed

Not supported

Top of Page