ONTAP Discussions

Moving Root Volume in Cdot

TMADOCTHOMAS

i need to move a 8.3.2 cdot root volume to a different aggregate. I am using the following KB article as a guide:

 

https://kb.netapp.com/support/s/article/ka31A0000008gyeQAA/How-to-non-disruptively-create-a-new-root-aggregate-and-have-it-host-the-root-volume-in-clu...

 

Unless I am missing something, I see one major issue with this approach. In the 7-mode approach, which I've done (see link below), you snapmirror the contents of the existing root volume to the new one, so you don't lose any contents. The cdot article describes creating a brand new volume without transferring the contents. Are the contents transferred "behind the scenes" once you tell the OS where the new root volume is? Would love to hear from anyone who has done this. Thanks!

 

https://kb.netapp.com/support/s/article/ka31A00000012HuQAI/how-to-move-or-rename-the-root-volume-on-a-storage-system 

6 REPLIES 6

AlexDawson

Hi there,

 

In Clustered ONTAP, all configuration of the cluster is stored in replicated databases - RRDBs - the procedure listed takes care of re-replicating these into a new qualified root volume, however system diag/crash logs will not be retained through this process.

 

Configuration of storage virtual machines are stored in seperate volumes on data aggregates volumes on the root aggregate (not root volumes), so they are not impacted by this.

aborzenkov

@AlexDawson wrote:

however system diag/crash logs will not be retained through this process.


Not only that, but any non-default content of root volume will be lost. This includes updated firmware files or DQP. So I can imagine corner case when user has brand new disks requiring updated DQP; then it won't be available on new root. I am not sure what are the consequences though (hopefully it comes up and allows installing missing files). But as there is apparently no way to be alerted about such situation, this requires user to manally track any extra files that may have been installed.

 

AlexDawson

DQP and firmware packages can be added back in easily, but you're right - it would be a fairly silent failure. I believe MyASUP risks will show it though. Most drives will autoqualify fine now, but it did used to be a big issue.

TMADOCTHOMAS

AlexDawson and aborzenkov,

 

Thank you for your replies! That answers my question. It's pretty unfortunate that something that was previously so easy (i.e. snapmirror the volume to retain contents) is no longer doable. i can easily add the DQP and firmware files back but what a pain to have to do it!

 

Alex I did have one follow up question. You said:

 

------------------

Configuration of storage virtual machines are stored in volumes on the root aggregate (not root volumes), so they are not impacted by this.

------------------

 

The root aggregate only contains the root volume, right? So I'm not following what you mean by volumes on the root aggregate. Are you referring to SVM root volumes?

AlexDawson

Sorry, my mistake - the SVM root volumes don't go on the root aggregate! Anywhere but!

And yes, your comment about the difficulty of this task is well heard - you will see that it is much easier in 9.0 and beyond

TMADOCTHOMAS

Thanks Alex! Yeah we're hoping to move to 9.x by years' end.

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public