Recently we have implemented a SAN migration for DMX to VMAX. Upon dealing with the IBM Qlogic pass-through switches a few things were determined. First thing of note is the fact that a pass-through fibre switch doesn’t act like a normal fibre switch, as it has no real intelligence. There is no ability to connect the qlogic pass-through switches to different SANs on the same qlogic switch. If you have redundant switches (typically 4 in a blade chassis environment) then you can leverage the other switches to your advantage. One such was is to have 2 of the fibre qlogic pass-through switches connected to the existing SAN, and two to the new SAN (assuming new cisco switches as well).
However, when you cable this up, you may run into some issues, so the process below can help alleviate that.
For the qlogic switches which are going to be used for the new environment, get a dump of the flogi db so you know what WWNs are logged in. Armed with this information, you can determine on the AIX blade system what WWN is logged into that SAN (and at the same time determine what IO fibre module it is).
The dump output from the flogi DB will indicate that qlogic switch logged in on the fc port, as well as the WWNs for the systems. The qlogic switch WWN can help you determine which qlogic switch (and in what module) it is located. Use the Advanced Management Module (AMM) to get a list of the qlogic fibre switches, what IP they are at, and in what IO Module they reside. On the AIX side, you can run a couple of commands to determine the hba and it’s referring WWN with a command such as:
lsdev |grep fcs | awk {'print "echo " $1 ; print "lscfg -vpl " $1'} |sh | egrep 'fcs|Network'
Now that you know which hba cards are affected, you can disable them (preferably one at a time) and then delete the child device of the hba so it stops trying to communicate with the old SAN. (NOTE: Simply setting the port to offline or down on the affected qlogic switch may work temporarily, however, upon putting the port back online the AIX system will get flooded with Path Failed and Path Recovered errors, in addition to Buffer Overflow errors causing your load average to skyrocket).
The best way to accommodate this change is to put the fcsX devices into a “Disabled State” and then once the paths are disabled, to remove the child hba device. Like so:
lspath |sort |uniq | grep fscsi0 | awk {' print "chpath -s Disabled -l " $2 " -p " $3}' | sh
Once the paths are confirmed as disabled, you can delete the child fcs devices with: rmdev -dRl fscsi0
Replace “fscsi0” with the relevant child hba device on your system. Repeat for the others (if applicable). Now that is done, you can disconnect the affected fibre cable(s) in the affected qlogic pass-through switches. Afterwords, you can run new fibre strands from your Qlogic switch modules to the new SAN switches. NOTE: If you had a problem in the past and set your qlogic switch / hba’s to a specified speed (w/o auto-negotiation) this should be set back to auto-negotiation, as it can interfere with some of the newer SANs. This would be an opportune time to update the port mappings as well. Just ensure no systems are connected to it, as changing the port mappings with a connected blade(s) can cause file system corruption.
After everything is run, and re-connected, the connections to the OLD SAN should be removed. This will probably involve removing the hba child devices and potentially removing the zoning on the old SAN switch for the affected AIX system.