Procedure for replacing 4 switches

You have options .. And it's a good thing

However it's better if you describe how switches are interconnected. A topology may be of great help

-s-

there would be less disruptions if you add the new switches to the existing fabric first.
once your switch merges into existing fabric, you can move over the hosts/arrays and then demise older switches.

And what's even better: if you used wwn zoning, you could simply unplug patch cables from the old switch and plug them into the new one and the zone would be up and running again without any reconfiguration.
Although: be aware of HPUX, since that is dependant of FCID's and you might need to rescan for the lun's again and you need to do some magic in UX to get volume groups working again.

Magic ?? What's magic ??

You need to shut down your host, boot in single user mode, create an io-map (a file that associate hardware stuff in the host with corresponding kernel drivers and instance numbers) modify it to reflect new FCIDs, push the new map in the kernel, reboot touching wood and finally verify that everything is at its correct place. If something is still broken, jump again at the beginning of the procedure .. Magic ?? I don't think it's magic .. it's a nightmare

We don't have HPUX, only Sun Solaris and Windows so that shouldn't be a problem.

Blessed you !!

If you still have free ports on your edges, configure new switches with valid and available Domani IDs, create ISLs from existing edges to new cores, verify that everything is working as expected and finally remove old ISLs to old cores. It looks like the best "procedure" ...

@everybody: Any other idea on this ??

its same idea as mine

Whoahahahahaha... nightmare, hahahahaha

i think a more elegant and bullet proof way of doing this on HPUX is to export the volume group while creating a map file, do your SAN work ..ioscan/insf -e ..and re-import your VGs with your map files.

nothing need to be worried about the VG if only the CTD number is changed as the LVM can still collect all the disk with the lvm header/vgid informarion.

the thing to worry about is the ctd of cluster lock vg which is hard coded in the cluster config file . Cluster cant come up this case. we did a work around in simialr cases by keeping the ctd device files of both old and new path with the same major&minor number. I mean update the old device which is in config file with the same major/number as the new path/ctd.

cool ..so no need to recompile the cluster ?

that's the magic I was talking about

"cool ..so no need to recompile the cluster ?"

yes, no need. Also the recompiling the cluster requires the whole cluster need to be down (all the nodes)

so when you re-created new device with major/minor numbers of the old ctd device ..did you do it on the fly , without taking the cluster down ?

Interesting idea..... The FCID doesn't change if I'm correct, so UX doesn't need a wizard to get it all working again, which is good.