spare parrot
Converting existing volume snapmirror relationships to SVM-DR, which will require creating new SVMs on the destinations, and using >vol rehost to move the existing DP volumes to the properly named and subtyped SVM.
I ran into a snag, tho. our dev/test team has ~10 volume clones based off the production Oracle mirror destination, which are currently nfs mounted and used. If I move the clone source to a different SVM, how does that impact the cloned volumes?
merry crane
you can in-place convert a volume snapmirror to an SVM DR relationship
here is how it's done
spare parrot
Yes, I know, have done that before. Tryign to do it here, but have issue with clones using a volume I need to rehost to a new svm to enable svm-dr
spare parrot
I think what I really need to know is if I rehost the parent volume of 40x vol clones, will they keep running?
today: parent vol and clones live in svm2
Future: parent vol lives in svm1_dp, clones that exist and get created going forward use the [-parent-vserver] option but live in svm2
Such a weird situation, thinking I just need to test it out.
spare parrot
well...fsck, [vol rehost] errors out if vservers aren't the same subtype. Damnit.
spare parrot
And can't rehost a volume if it's the parent of a clone volume.
be nice if those 2 caveats were mentioned in https://docs.netapp.com/us-en/ontap-cli//volume-rehost.html#description
merry crane
probably better here: https://docs.netapp.com/us-en/ontap/volumes/rehost-volume-another-svm-task.html
this works very well (from my experience)
if you don't have a GitHub account let me know and I can submit it as an issue and PR