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 

[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.