Moving root volume

[JOHNYTHENMARRY]

  Hi,

  I need to move the root volume form one aggregate to another onthe same filer. Can we use vol copy command and destroy the existing aggregate.
If someone knows the steps please share

Thanks

Johny

[tom_taelman]

Johny,

You can simply move the current root volume to the new aggregate. The procedure goes something like this:

vol create vol0_new aggrSATA 100g

vol restrict vol0_new

vol copy start -S vol0 vol0_new   (you can also use snapmirror)

...wait...

vol options vol0_new root

reboot

...wait...

vol offline vol0

vol destroy vol0    (delete the old root volume)

aggr offline aggr0

aggr desstroy aggr0    (delete the old root aggregate)

vol rename vol0_new vol0    (rename the new vol0 back to the original name)

[AGUMADAVALLI]

Hi there,

snap create -V vol0 vol0-snap

vol create vol0_new <aggr name> 250g

vol options vol0_new create_ucode on

vol options vol0 convert_ucode on

vol lang vol0_new en_US

options ndmpd.enable on

ndmpcopy /vol/vol0 /vol/vol0_new

vol options vol0_new root

vol rename vol0 vol0_old

vol rename vol0_new vol0

vol status

vol offline vol0_old

You should be good to go.

thank you,

AK G

[mjschneider]

Just remember that "reboot" is required after setting 'vol options <volname> root'.  Doing a failover won't suffice.

[aborzenkov]

Just remember that "reboot" is required after setting 'vol options <volname> root'.  Doing a failover won't suffice. 

It will. cf takeover/cf giveback is enough. It provides for moving root volume almost non-disruptively (almost because existing NFS mounts will still become stale and need remount)

[mjschneider]

aborzenkov wrote:
Just remember that "reboot" is required after setting 'vol options <volname> root'.  Doing a failover won't suffice. 
It will. cf takeover/cf giveback is enough. It provides for moving root volume almost non-disruptively (almost because existing NFS mounts will still become stale and need remount)

I'm echoing what a netapp installer told me just last week.  But to be honest i'd take your word over the installer's

[BRENDONDHIGGINS]

I have moved a few vol0s over the years and cf takeover is good, because if you get something wrong you still have the original vol0 active in a taken over state to recover from, as long as you do not use cf giveback -f.  With care the above procedure will work.

Good luck

Bren

[scottgelb]

Good discussion here... most use snapmirror, vol copy or ndmpcopy.  Lately I use vol copy -S since less to clean up after. and copies all root with all snaps.. for snapmirror the baseline snaps  are an extra clean up step (although good to keep incremental updates prior to cutover if that is goal).  For ndmpcopy, many leave (but I prefer to delete) the restore_symboltable file on the target... not needed after the copy and cutover so good to delete and clean up root by removing that file which can be fairly large.  But I always like having a snapmirror copy of root on a different aggregate as backup (discussion of that on some other posts here).

[scottgelb]

Another thought... if 32 bit root and you want to go to 64-bit root ndmpcopy is usually the best method or only method... unless on 8.1 where you can snapmirror 32 to 64 but can't vol copy 32 to 64bit.

[davidrnexon]

Hi Johny, I usually use snapmirror to copy the root vol from one aggregate to another, once the snapmirror is finished, I quiesce it, break it, remove the baseline snapshots, mark the vol as root which then marks the new aggregate as root.

The either reboot the controller or issue a cf takeover and cf giveback

[jhenschell · Accepted solution]

Hi Johny, here is the method I just recently used to move vol0;

1.       Disable the cluster: cf disable

2.       Check the size of current vol0: vol size vol0

3.       Create a new root volume on the SATA aggr:   vol create vol0_new aggr0_sas <SIZE>

4.       Copy the data to the new volume: ndmpcopy /vol/vol0 /vol/vol0_new

5.       Rename the old root volume: vol rename vol0 vol0_old

6.       Rename the new root volume: vol rename vol0_new vol0

7.       Flag the new root volume as the root volume: vol options vol0 root

8.       Reboot the controller: reboot

9.       Confirm the SAS aggr now hosts the root vol0: aggr status                                                                                                                         on the left under Options it should say root on aggr0_sas

10.   Offline and destroy the old volume vol0: vol offline vol0_old    and    vol destroy vol0_old

[scottgelb]

Looks good... I would add a step at the end "priv set advanced ; rm /vol/vol0/restore_symboltable" to clean up the ndmpcopy

[jhenschell]

Thanks Scott. That’s a step I’ve not heard of before.

[scottgelb]

sure...check your vol0 and you will see the restore_symboltable file left behind..

[FLNASHSMS]

I haven't done it on a production system, but I have in pre-deployment and on a simulator using the procedure at https://communities.netapp.com/thread/14353

[JOHNYTHENMARRY]

Hi,

Thanks for you input and i could change the root Vol to diffrent Aggr

Thanks

Johny

[kkaushal2]

Below is what I have used in past

USING NDMP:

1. Enable NDMPD

2. ndmpcopy /vol/vol0 /vol/<new vol0>

3. cifs terminate

4. vol rename vol0 vol0_old (rename existing root volume)

5. vol rename <new_vol0> vol0 (rename new root volume to vol0)

6. vol options vol0 root

7. Reboot Storage System

8. Test FilerView access (prior to Ontap 8.1). Normally this does not work anymore, so run "secureadmin setup ssl" to recreate the ssl certificate, and filerview should work again

9. vol offline vol0_old

10. Check access to C$ share

[sanjivv]

Hi,

Check this KB article also

https://kb.netapp.com/support/index?page=content&id=1010097

Sanjiv

[IGORSTOJNOV]

This is interesting, I used to use ndmpcopy as well but now... How about vol move?

Wouldn't something like  vol move start vol0 <new_aggr>  accomplish the same, with a lot less legwork?

[ERKANAKSOY]

You can't just move root volume to another aggr. Wish it was possible.

[IGORSTOJNOV]

Erkan, it is possible. Did you even read this thread?