You are correct and anyways migration would only work on the same filer.

Sorry for suggesting a dead end.

Joel

Michael Barrow wrote:

'snapmirror migrate' is only applicable for an existing SnapMirror relationship. In this particular instance, the SnapMirror relationship has effectively been torn down and a new relationship must be built.

On Wed, Dec 9, 2009 at 5:56 AM, Joel Krajden <joelk@encs.concordia.ca mailto:joelk@encs.concordia.ca> wrote:

You might want to look at

Solution ID: kb40272
Last updated: 30 SEP 2009

Sample procedure using ' snapmirror migrate ' that avoids remounting
in a NFS environment



Joel


John Stoffel wrote:

                        "Fox," == Fox, Adam <Adam.Fox@netapp.com
                        <mailto:Adam.Fox@netapp.com>> writes:


    Fox> VSM (and therefore SM2T) will preserve inodes, but it will
    be up
    Fox> to you to preserve the FSID of the original volume on east.  If
    Fox> you go into priv set advanced, you will find 'vol
    read_fsid' and
    Fox> 'vol rewrite_fsid' which can accomplish this.  Be aware that
    Fox> Rewriting the fsid requires the volume to be restricted and you
    Fox> will need to rewrite the original one first to something
    totally
    Fox> different.  FSIDs must be unique not only within a
    controller but
    Fox> within an HA-pair if you want failover to work properly.

    Ouch!  Sounds funky and possibly trouble.

    While I don't have any common snapshots between west> and east>
    filers, I do have some common snapshots on each filer for other
    snapmirror relationships, since west> is also snapmirroring tools to
    two other sites.

    Would it be possible to do the following:

         1) quiece all snapmirrors of tools from west> to south> and
            north>
            - will this leave me with two snap shots for the west->north
              pair, or will snapmirror automatically cleanup when done?

         2) comment out tools entries on all filers: west, south,
    north &
            east.

         3) on west> (my source), do 'snap rename
    north(####)_tools.1234 \
               east(######)_tools.1234'
               4) on east> snapmirror resynnc tools

            - wait until competed

         5) on west> snap rename east(######)_tools.1234 \
               north(######)_tools.1234
         6) do snap update tools on east, north, south to make sure they
            can all update again.

         7) re-enable snapmirror.conf entries for tools.

    Or I wonder if I need to interrupt the west->north snapmirror in
    progress, and make sure I only rename the more recent snapshot, so
    that I still have valid snapshots between west->north, and now a
    second one to re-purpose as my west->east pair base?

    Any hope?  
    Thanks,
    John



    Fox> While these commands are perfectly safe when used properly,
    they are
    Fox> guns so point them away from you (i.e. know what you're
    doing before you
    Fox> it or you could have a disruption you don't want).

    Fox> -- Adam Fox
    Fox> Systems Engineer
    Fox> adamfox@netapp.com <mailto:adamfox@netapp.com>


    Fox,> -----Original Message-----
    Fox,> From: John Stoffel [mailto:john.stoffel@taec.toshiba.com
    <mailto:john.stoffel@taec.toshiba.com>] Fox,> Sent: Monday,
    December 07, 2009 5:50 PM
    Fox,> To: toasters@mathworks.com <mailto:toasters@mathworks.com>
    Fox,> Subject: Redoing snapmirror to a destination


    Fox,> Guys,

    Fox,> Do to stupidity on my part, I managed to accidently delete
    a snapshot
    Fox,> on the source side of a snapmirror pair, so that
    snapmirror can't
    Fox,> continue.  It's not critical, it's just our tools area,
    which isn't
    Fox,> updated frequently.

    Fox,> So now I want to re-snapmirror, but I want to limit the
    downtime of
    Fox,> the clients on the destination side as much as possible
    when I switch
    Fox,> them to the new re-snapmirrored volume.

    Fox,> Currently, my clients mount east:/vol/tools, so what I'd
    like to do
    Fox,> is:

    west> snapmirror store tools rst0a,rst1a

    east> vol create tools ....
    east> vol restrict tools
    east> snapmirror retrieve tools_new rst0a,rst1a

    Fox,> Now for the tricky part:

    east> nfs off
    east> vol rename tools tools_old
    east> vol rename tools_new tools
    east> nfs on
    east> exportfs -a -v

    Fox,> so that all my clients see (on a read-only volume) is a
    quick outage
    Fox,> or pause in NFS traffic, then they just continue on using
    tools and
    Fox,> such as usual.

    Fox,> Or will I be forced to reboot all of my client machines
    one by one?
    Fox,> Which will be truly truly truly painful...

    Fox,> The general snapmirror update and cleanup of the old volume is
    Fox,> trivial.  It's limiting the outage to my clients that I
    worry about.
    Fox,> Thanks,
    Fox,> John
    Fox,>     John Stoffel - Senior Staff Systems Administrator -
    System LSI Group
    Fox,>   Toshiba America Electronic Components, Inc. -
    Fox,> http://www.toshiba.com/taec
    Fox,>        john.stoffel@taec.toshiba.com
    <mailto:john.stoffel@taec.toshiba.com> - 508-486-1087







-- 
| Joel Krajden           | Rm: EV-7105,  Tel: 514 848-2424 3052    |
| Core Technologies Mgr  |                                         |
| Engineering &          | Email: joelk@encs.concordia.ca
<mailto:joelk@encs.concordia.ca>          |
| Computer Science       |                                         |
| Concordia University   |  In a circus, the clowns are supposed   |
| Montreal, Canada       |  to make you laugh, not cry.            |

-- Michael Barrow michael at barrow dot me