ONTAP Discussions
ONTAP Discussions
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
Solved! See The 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
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)
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
Just remember that "reboot" is required after setting 'vol options <volname> root'. Doing a failover won't suffice.
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)
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
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
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).
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.
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
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
Looks good... I would add a step at the end "priv set advanced ; rm /vol/vol0/restore_symboltable" to clean up the ndmpcopy
Thanks Scott. That’s a step I’ve not heard of before.
sure...check your vol0 and you will see the restore_symboltable file left behind..
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
Hi,
Thanks for you input and i could change the root Vol to diffrent Aggr
Thanks
Johny
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
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?
You can't just move root volume to another aggr. Wish it was possible.
Erkan, it is possible. Did you even read this thread?