ONTAP Discussions

How to migrate a Snapmirror SVM-DR source SVM to a new cluster?

skayep
2,469 Views

Is there a proper procedure How to migrate a Snapmirror SVM-DR source SVM to a new cluster?

details: both clusters are running on the same version 9.12.1.

both clusters are peered to each other. SVMs to be migrated has a CIFS share with non-default qtree created.

 

i tried to run the command on privilege advance mode:

vserver migrate  start -vserver <vserver_name> -source-cluster <source_cluster_name> -check-only TRUE -aggr-list  <destination_aggregate_name>

 

The error # 1:

There are no network ports on the destination cluster "<destination_cluster_name> where the reachability is confirmed for the following IP addresses: 192.168.20.x

 

The source SVM has 2 LIFs the operational one (192.168.10.x) having status admin UP and the 2nd LIF is 192.168.20.x which is status admin down. so i removed the 2nd LIF to erase my doubts then run the vserver migrate command again but another error appeared:

 

Error # 2:  Cannot migrate Vserver "vserver_name" because a non-default qtree "qtree_name" exists on the volume "vserver_name_volume_name" Migrating Vservers containing non-default qtrees is not supported.

 

My question: do i have to delete my qtree for me to be able to migrate the SVM? how can i delete a qtree with files and folders on it? If i use -force in deleting qtree my data will be gone.

 

Please shed light on me how to migrate my SVM to the new cluster?

 

Skayep

 

 

 

 

 

 

 

 

 

 

 

 

1 ACCEPTED SOLUTION

skayep
2,073 Views

Because of the limitations we are into i decided to create an snapmirror relationship between the old cluster to the new cluster (destination) then later stop the changes/writes by setting the source LIF to status down  on the source SVM then run an snapmirror update then break the relationship for the destination to become the volume writable or RW. Then set the destination SVM as the production SVM then add the old DNS of the source SVM as alias to the destination SVM then set the LIF on the destination SVM to status admin up since it was down when it was still a destination SVM from the source.

 

  

View solution in original post

6 REPLIES 6

TMACMD
2,434 Views

Maybe someone else can chime in here, but there is a document someplace. That document, in my opinion forgets one very very important step(unless it’s been fixed recently):

 

 it basically says:

 stop source svm

 start destination svm

 

 what’s missing:

stop source svm

 snapmirror update svm:destination 

 start destination svm

 

 just remember that when you are reviewing

skayep
2,274 Views

hi TMACMD,

 

thanks for your reply. you mean i have to stop the source SVM before doing the vserver migrate command?

 

Skayep

ansley_tj
2,392 Views

SVM Migrate started supporting qtrees with ONTAP 9.14.1.

Also, it does not currently support migrating SVMs that are in an SVM-DR relationship

See SVM data mobility overview (netapp.com) for support information.

Thanks
Tony Ansley
I am a NetApp employee.

skayep
2,272 Views

Hi Ansley_TJ,

 

Thanks for your reply. So there is no way i can migrate my SVM to my new cluster non-disruptively.  My source cluster is FAS and the destination cluster is AFF series. Any KB that i can read that SVM migration doesn't support qtrees prior ONTAP 9.14.1 and  unable to migrate an SVM which is a part of SVM-Dr relationship?

 

Skayep

skayep
2,116 Views

Hi Ansley_TJ,

 

You mean i need to upgrade my Ontap to version 9.14.1 to support SVM qtrees then break the SVM-DR relationship of the SVM then run the SVM migrate command. is that what you mean?

 

Skayep

skayep
2,074 Views

Because of the limitations we are into i decided to create an snapmirror relationship between the old cluster to the new cluster (destination) then later stop the changes/writes by setting the source LIF to status down  on the source SVM then run an snapmirror update then break the relationship for the destination to become the volume writable or RW. Then set the destination SVM as the production SVM then add the old DNS of the source SVM as alias to the destination SVM then set the LIF on the destination SVM to status admin up since it was down when it was still a destination SVM from the source.

 

  

Public