How To: Migrating VMware ESX 2.5 Datastores with EMC SANCopy #fromthefield

By May 31, 2011EMC, How To, Storage, VMware

I know this is a little old-school, but since I didn’t find a good reference anywhere online … I am going to cover migrating VMWare ESX 2.5 datastores with EMC SANcopy in this month’s installment. If you find yourself in this situation—you will know that it works and how it’s done. I recently ran through this migrating from an EMC Clariion CX-300 to a new VNX5300.

High-level, here are the steps to migrate an ESX 2.5 Datastore with SANCopy
1. Document, Document, Document
2. Setup SANCopy
3. Shut down Guests and Host
4. Start Copy Sessions
5. Reconfigure host to access new array
6. Restart Host and then Guest

This how-to makes some assumptions.
– You know your way around Navisphere and Unisphere
– You know your way around the VMWare ESX 2.5 management interfaces

1. Document, document, document. I can’t stress this enough; it’s key to know exactly how things are set up, because it’s essential that we make it look the same on the target system. It is invaluable to have an up to date CAP report or Array Configuration report. The goal is to make as little change for the ESX 2.5 host as possible and the more you record upfront, the easier your life will be. The key things to record for each of the attached Datastores are the following:
– Source LUN ID
– Host LUN Id (this is configured and shown in the Storage Group LUN properties)
– Owning SP (this is in LUN properties)
– Size in GB (If this is not an integer value record the number of blocks in LUN properties)
– LUN WWN (this is in LUN properties, but the best place to get this is from a CAP report – because you can copy and paste)

Here’s a sample table you can use to record the data:

2. Setup SANCopy. In order to run SANCopy at least one of the arrays needs to have the SANCopy license enabler installed. It makes the process significantly easier if the enabler is installed on both arrays, but at a minimum it should be installed on one array, preferably the target array. If the enabler is installed on both arrays, both arrays will need to be in the same Navisphere management domain. Once the enabler(s) are installed, zone the front end ports on each array to the front end ports on the partner array (i.e. SPA0 on source to SPA0 and SPB1 on target, and so forth). When the FE ports are zoned, create a SANCopy Storage Group on the source array and update the SANCopy connections on both arrays. The initiators should show up and register automatically on the source array.

The next part is to setup the SANCopy sessions. Put each of the source LUNs to be replicated into the SANCopy Storage group and then run the SANCopy wizard in order to create a session for each LUN. The wizard walks you through selecting the SANCopy array (target array), Source LUN (use the enter WWN and paste the LUN WWN in the entry field), Target storage device (right-click and select target storage), and the session details. I find it valuable to set the name of the session to something descriptive, like the source LUN name, size, etc. If both arrays have the SANCopy enabler installed the selection process is a little more intuitive as you can see the LUN names, size, etc.

3. Shut down Guests and VMWare Host. SANCopy is an array-based block copy that copies all blocks in a LUN sequentially to a target LUN. In order to get a consistent useable copy the host cannot access the source or target for the duration of the copy. Ideally, when shutting down the VMWare guest machines, set the automatic restart value to disabled so they don’t try to start when the new target datastores are mounted when VMWare starts.

4. Start SANCopy Sessions. By default SANCopy sessions have a throttle value of 6—I typically change this to 8 or 10 in a migration effort for best throughput. This is equivalent to setting a LUN migration to High. If you are going to start multiple simultaneous migrations, you may need to adjust the Active Sessions per SP from 2 to 4. Start the sessions and monitor until all sessions complete.

5. Reconfigure host to access new array. Zone the host to the new array making sure to disable or delete the zones to the old array. Power on the host and interrupt the boot post cycle at the HBA BIOS screen. At this point the HBA should have logged in to the target array—if it has not, re-check zoning and/or use the HBA BIOS utility to rescan targets. Once the HBA is logged in to the array, use the Connectivity Status tool to manually register the host connections. When the host HBA connections are registered, create a Storage Group adding the LUNs and paying careful attention to setting host LUN id values to match the source array configuration. Add the host to the storage group and exit the HBA BIOS utility and reboot.

6. Restart Host and then Guests. When the host powers up verify that the datastores are visible and browsable using the VMWare Client utility. If everything looks good power on the guests and you are done.

A couple of thoughts … this example was migrating between two Clariion arrays, but SANCopy also works for migrating data from HDS arrays, HPQ arrays and other SAN platforms to a Clariion—as long as the LUNs are identifiable by LUN WWN or storage array Port WWN and LUN id.

Photo credit: alex.ragone via Flickr