Are all the hosts connected with dual HBA - one to each fabric? You should be able to move over one half at a time without hosts losing access to their disk (assuming you can handle running on one path during the migration).

Do you have any free ports on your arrays to plug them into the new fabrics or do you need to move the array ports over at the same time as the hosts?

Great questions Shewitt. These are key to answer to describe how best to migrate.

Thank you.

Shewitt, CiscoKid,

Yes. All the hosts are connected with dual HBAs - one to each fabric. So yes, that is one option to move half of the array ports and half of the hosts at one time. Can I prestage zoning on Cisco side to reduce downtime and mistakes? Can I write script to run on Cisco? How?

I don't have free ports on arrays so I need to move everything at the same time.

Thanks in advance for your help,

YP

Hello,

You could take a copy of the config and manually edit it before hand and then upload it to the switch. You have to be very careful though as you can cause a lot of problems easily if you make a mistake.

If this is a large, complicated, or affects critical hosts; I would strongly recommend using EMC professional services to do the migration. I've heard many horror stories of migrations gone bad when customers tried it on their own.

Thank you.

We did that exact move and utilized IVR.
I ISL'd the McData directors into our Cisco, gave them a separate vsan and migrated the hosts 1 by 1. If the host had 2 hba's and ran powerpath, it was pretty easy to migrate that host. If only a single hba, the host obviously needs to come down.
You can pre-zone using CLI in the cisco's.

I moved all the hosts over to the Cisco first, utilizing IVR and placing the hosts in a different vsan than the mcdata ports then migrated the storage ports.

We have all EMC - DMX, Clariion and Sun, Windows, Linux, and AIX hosts.

You do have to be cognizant of the driver levels for windows and solaris and the odm database revs on AIX. Also, you have to have the proper lettings on AIX so it can automatically re-discover its luns if it moves from one switch port to another.

some procedures I put together for our AIX environment:
1. enable fast_fail and dynamic tracking

lsattr -El fscsi : will return the following data. It will return that dyntrk is currently set to NO and that dynamic tracking of fc device is FALSE. also will report that it is configured for 'delayed fail' instead of 'fast fail'.

Both hba's will need to be configured to have dyntrk set to YES, dynamic tracking of fc devices to TRUE, and 'fast fail' enabled.

chdev -l fscsi0 -a fc_err_recov=fast_fail - or whatever the fscsiX value is
chdev -l fscsi1 -a fc_err_recov=fast_fail - or whatever the fscsiX value is

chdev -l fscsi0 -a dyntrk=yes - or whatever the fscsiX value is
chdev -l fscsi1 -a dyntrk=yes - or whatever the fscsiX value is

A reboot is required after changing the fast_fail setting. You can choose to reboot after performing a powerpath upgrade ¿ in step 2.

2. upgrade powerpath to 4.5.1
You can upgrade powerpath 4.3 to 4.5 without a reboot (providing you close all apps that use powerpath devices before installing 4.5.1) and you do not have to remove the previous powerpath version.

Jimbo,

these AIX settings ..were they recommended by EMC or IBM ? Would you please point to some documentation that you used ?

Thanks a bunch

during our migration we had issues with an AIX host. We opened a case with EMC and those were the findings the engineer returned with. I rewrote them so they were more understandable to my mgmt team and my AIX admin(s).

We implemented them and our issue was resolved. I recommend obtaining grabs and having an EMC engineer review them for potential configuration issues.

Hello Jimbo and all,

Please keep in mind that you would want to contact you local EMC support people about log collection and review of the configurations for any issues. You can also submit the EMC Grab (collection of logs) into HEAT (Host Environment Analysis Tool) yourself via Powerlink. This will scan the EMC Grabs against the EMC Support Matrix and tell you of any issues it locates.

EMC Phone Support should only be contacted for Break / Fix type issues when you are currently experiencing a problem. Any type of preventative check issues or migration concerns should be directed first to the EMC Customer Engineer and the local EMC field staff. EMC phone support is first and foremost directed to resolution of production impacting customer issues. Local EMC field resources can best assist customers with other issues such as you have noted.

Thank you.

Thanks a lot everyone, This has been great help.

I will use all of you guys input to come up with the procedure. Since we have big environment with limited downtime, we are thinking to migrate small subset of storage/hosts at one time and I am sure we will use EMC people to make sure our plan is good.
Again, Thanks a lot everyone
YP

YP, I see you marked your question as answered. Could you also reward those hard working guys with some point to show other visitors which were the absolute best answers on this issue ?