Skip to main content
NetApp Knowledge Base

How to non-disruptively migrate a node's root volume/aggregate onto new disks in ONTAP 9?

Views:
19,598
Visibility:
Public
Votes:
17
Category:
ontap-9
Specialty:
core
Last Updated:

Applies to

ONTAP 9

Description

  • ONTAP 9 supports the feature system node migrate-root that non-disruptively migrates the root aggregate to different disks on a storage controller. 
  • The command is a background script similar to an Automated Non-disruptive Upgrade (NDU).
  • The script performs validation checks and all steps required to migrate a node's root volume. 
  • Migration to partitioned disks is supported in ONTAP versions starting in 9.3P15, 9.4P8, 9.5P5, and 9.6 and all later versions. 

A failover (takeover and giveback) is part of migrate-root. Similar precautions as NDU should be followed, including and not limited to:
  • The node and its partner are healthy
  • Storage failover is possible
  • CPU and disk utilization is under 50% during the activity
  • NAS LIFs are configured with appropriate failover targets
  • SAN clients have MPIO configured correctly and can tolerate storage failover 
  • SnapMirror transfers are quiesced

HA must be configured in a 2-node cluster to prevent out of quorum (OOQ) event.

cluster ha modify -configured true

Due to improvements and bug fixes, it is highly recommended to upgrade to ONTAP 9.2 and later prior to using this command.

system node migrate-root CLI man page

9.0 and 9.1 system node migrate-root

Start the root aggregate migration on a node

Availability: This command is available to cluster administrators at the advanced privilege level.

The system node migrate-root command migrates the root aggregate of a node to a different set of disks. You need to specify the node name and the list of disks on which the new root aggregate will be created. The command starts a job that backs up the node configuration, creates a new aggregate, set it as new root aggregate, restores the node configuration and restores the names of original aggregate and volume. The job might take as long as a few hours depending on the time it takes for zeroing the disks, rebooting the node and restoring the node configuration.

Parameters

-node {<nodename>|local} - Node

Specifies the node that owns the root aggregate that you wish to migrate. The value local specifies the current node.

{ -disklist <disk path name>, ... - List of Disks for New Root Aggregate

Specifies the list of disks on which the new root aggregate will be created. All disks must be spares and owned by the same node. Minimum number of disks required is dependent on the RAID type.

-raid-type {raid_tec|raid_dp|raid4} - RAID Type for the New Root Aggregate

Specifies the RAID type of the root aggregate. The default value is raid-dp.

Examples

The command in the following example starts the root aggregate migration on node node1:

cluster1::> system node migrate-root -node node1 -disklist 1.11.8,1.11.9,1.11.10,1.11.11,1.11.12 -raid-type raid_dp

9.2 and Later New feature added

9.2 and Later system node migrate-root

-resume [true]} - Resume a Failed Migrate Operation

Resumes a failed migrate-root operation if the new_root aggregate is created and the old root aggregate is in the restricted state.

Procedure

  1. An appropriate number of spare disks is required. Check the patform's recommended sizes in Hardware Universe. Determine available spare disks:

::> storage aggregate show-spare-disks -owner-name node1

  1. Enter advanced mode to run the command and specify the new disks to be used. This will start the root migration.

::> set adv
::*> system node migrate-root -node node1 -disklist 1.11.8, 1.11.9, 1.11.10, 1.11.11, 1.11.12 -raid-type raid_dp

  1. Check the status of the migrate-root and note any errors. It can take 20 to 40 minutes for the job to timeout with an error.

::*> job show -name "Root Aggregate Migration Job" -instance

  1. In ONTAP 9.2 and later, you can resume the job.

::*> system node migrate-root -node node1 -resume true

  • Normally, the root-migration will be successful and transparent, however there are some rare situations that can cause the script to fail.
  • A possible failure includes that a node boots up with a new root aggregate and the script fails to continue, requiring additional manual cleanup steps.

For further assistance, contact NetApp Technical Support and reference this article to assist in the recovery.

Sign in to view the entire content of this KB article.

New to NetApp?

Learn more about our award-winning Support

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.