It can be used to migrate a volume to a different volume. Both the volumes need to be in a SM relationship tho. As the documentation points out, it will do all the leg work of moving the NFS connections to the destination volume, restricting the src volume etc.
Imagine you have a volume built on FC drives and you want to archive it off to a SATA volume within the same controller. Once you set up the SM relationship, the last cutover can be done using this option..
While this migrate is happening, the NFS clients will see a small hiccup and will continue to resume...
I am a big fan of the snapmirror migrate function however there are some extra considerations. It is similar to vfiler migrate but at the volume level instead of virtual filer...but it is not as automated as vfiler migrate (see second paragraph below). The process does a final mirror update, restricts the source, breaks the destination mirror, moves the nfs file handles to the destination, changes the destination volume fsid to match the source. It is very effective intra-controller since the IP address doesn't change... if you use it between controllers...it would be harder to migrate with no downtime since clients would need a new ip to connect to or you would have to ifconfig down source controlle rand ifconfig up dest controller quickly...
In my experience with snapmirror migrate... it does not update cifs shares and nfs exports. The target of the share/export stays pointed to the RESTRICTED original source volume not the new desitnation. To make a seamless nfs cutover, you have to do a quick exportfs. For cifs, the client has to reconnect (what's new) but you also need to delete the old share and recreate it (write a quick cifs shares and cifs access script). Additionally, with LUNs after snapmirror migrate, the luns in the destination volume are brought online but they are not mapped, so you have to remap the lun to the igroup...don't migrate luns hot..disconnect from the host.
It would be great if more automated functionality was added to automate the cutover. (3 below)..the real use for the snapmirror migrate command by completing the steps below (although with ONTAP GX which has this as a key feature it might not make it into any 7G release unless an RFE for 7G could be addressed for the following):
1) update exports
2) update cifs shares
3) map luns to igroups
Adding to what Scott posted about using SnapMirror migrate, here are some items that I’ve witnessed from an actual cutover using it this past weekend at one of my clients.
First off, it does work as advertised and, when put together as part of a script, I was able to cut over 31 volumes to a different aggregate in 15 minutes time. However, I had to do this via scripting and, even then, there were some other items that I had to do (fix shares and exports) that I believe would be better if this was all encompassed in SM migrate. I'd like to add one more thing to Scott's RFE list and that is to reset the fs_sized_fixed option from on (done on the SM destination) to off after the migrate has completed.
I also wrote KB40272 a while ago on the steps needed to use "snapmirror migrate" to transparently move data in NFS environments. It gives exact steps and might be good for reference use as part of this thread.
@Madden, nice article, but what's the use if I read at the beginning : "Note that all NFS access must be stopped to the volume being migrated." !? Why, I thought snapmirror migrate functionality makes the cutover transparent for the client (at least if you also do the extra steps described in the kb).
Since the last reply is dated from 2009, any functionality added in between to the snapmirror migrate command (RFE from above) ?