VMAXhumpday, 4/16/2014 – Open Replicator pt. 2


Well, last week my Open Replicator post went over pretty good and I realized that I really needed to do another Open Replicator post…  This time it’s STONE COLD PULL Open replicator time.  Oh, and to throw something a little more different in?  Why not just do a VMAX to VMAX pull.  Oh this is gonna get fun!  Remember when I told you that control devices and remote devices are a good thing to keep track of?  Well here we go!

I like to use both Unisphere and the command line where it is appropriate.  Because I’m only migrating two servers in this example, and I need to get my new devices to talk to VMAX ports 8H1 and 5H1 (I originally zoned 8H1 and 5H1 on the new VMAX to the same on the old for OR purposes).

Here are the devices as shown in Unisphere for VMAX.  As you can see I’ve got 7 devices going to one server and 6 to the other.  They are all bound to different thin pools on the VMAX.


From here I need to hit the [>>] button and map them to the correct ports in order for my open replicator session to work (yes you can also easily do this in the CLI, but I like it this way in Unisphere).


Here it asks you where to map it to (you want to choose the ports your OR zoning is setup between arrays at).


I previously had already mapped these before I took the screen shot, but this is where it would show you the two or more ports you have selected.  It also allows you to manually select the LUN addresses, but I allow it to assign them automatically here because I don’t really care for OR.


Then it is going to show you a summary before you map everything.  Verify this is what you want and click ‘run now’ under ‘add to job list’.  This will map them pretty fast, so double check this is what you want!


OK here is the CLI stuff you’ve dreamed late at night about.  Check this magic out.  You can display what you just did to satisfy your geek desires.  symcfg -sid <sid of array> list -available -address -fa 8h -p 1…  repeat for the other ports you mapped and you’ll get something that looks like this:


Now isn’t that nice!

Alright.  Now let’s get some stuff setup to start copying!  I told you the whole control/remote thing would come in handy.  So your control devices in an open replicator pull operation is going to be your destination device.  So, you don’t want anything to be written to them while you are copying.  Yes I said that right.  Yes, kinda confusing.  What it should say is that you want to set your device to not-ready but it will be ready to receive data from the source lun you are copying.  To set device status to not-ready you need to go to the lun view you were previously in and select all devices, right click and set volume status:



Now you’re gonna get this and yes….you set it to not ready!  PLEASE MAKE SURE you don’t do this to production luns please.  Double check before you click OK.  A paranoid storage admin is a good storage admin!


Now they are all gonna look like this:


So you are ready to setup some stuff to start copying!  Shut down the physical host at this point so nothing is accessing the luns.

First create your device pairing files for your open replicator sessions.  Your control device is always first so this is gonna look the opposite of what I showed you last week.  Why am I doing this part in CLI Sangeek?  Well let’s just say it’s much faster than in Unisphere and you can create these files ahead of time to save you some time as well.


From here I will do a create operation:

symrcopy -sid <Array ID> -create -pull -cold -name <what you want to name> -pace <what pace…i set mine to 1 or 2> -f filename.txt

If all is well, your create will be created.

symrcopy -sid <Array ID> -query -f filename.txt

Will show you everything setup.  Verify before activation!

symrcopy -sid <Array ID> activate -f filename.txt

Watch stuff copy!


When all is finished, you’ll need to:

symrcopy -sid <Array ID> terminate -f filename.txt

Then.. repeat the mapping process in reverse by unmapping the devices from the OR ports.

Set the device status to Ready by repeating the set device status.

Then all you need to do is add them to the storage group, mask ’em up to a host and you should be good to go!

Of course, once things are all verified you will want to clean up the old VMAX stuff and take a nice long nap.  Afterall you probably just stayed up all night and it’s time to go to bed.

Hope this has been useful and you can see the process it takes to use cold pull open replicator from VMAX to VMAX.

Happy VMAXhumpday!




This entry was posted in EMC, VMAX, VMAX Hump Day. Bookmark the permalink.

2 Responses to VMAXhumpday, 4/16/2014 – Open Replicator pt. 2

  1. @dynamoxxx says:

    Worth mentioning is that you typically want to activate using -consistent if there are multiple devices per session. I like to always use that option even if it’s a cold pull or push.

    • sangeek says:

      Thanks dynamoxxx!!! I didn’t think it was needed for a cold pull/push but might be a good idea just in case… Also thanks for dropping by my Blog!

Leave a Reply

Your email address will not be published. Required fields are marked *