McData Fibre switch issues

[Don Spare]

We have recently installed an EMC Clariion with 2 McData fibre switches. One of the ports on Switch A has gone bad and will require us to replace the entire switch to fix the problem. In the meantime the cable has been moved to a working port.

Now for the bad news ... The EMC engineer who was prepping the new switch for installation told us something about having to use vgreduce or vgimport or other 'vg' commands after the new switch is in place. This is kind of scary to me as I am not that familiar with those commands and what they can or cannot do or, more precisely, what they are capable of destroying if not used correctly.

Has anyone had a similar experience? I need to know what EMC is talking about here and just how 'destructive' it might be. I really don't want to have to restore my system from tape just because we are replacing a redundant fibre switch.

[Jeff Schussele · Accepted solution]

Hi Don,

Assuming you have alternate links to your VGs, all they're saying is that you'll need to reduce the path that will "disappear" & then add back the new one. The problem is that 99% of the time a new switch will present a new controller instance. For EX. if the device *was* c5t3d4 after the switch replacement the new device may be c9t3d4. Same disk - just a new device file.
So I'd recommend you do a vgexport now for each VG as follows:
vgexport -m /etc/lvmconf/vg_name.map -psv /dev/vg_name
Then just before the switch AND after you've determined just *which* path is going away, do:
vgreduce /dev/vg_name /dev/cXtYdZ
for that path for *each* VG
Then after the switch you'll need to do
ioscan -fnC disk
to get the new devices recognized - then
insf
to install the new device files. Then you'll need to add the new alternate links with
vgextend /dev/vg_name /dev/dsk/cXtYdZ

That's all there is to it. The vgexport is just a safety net in case something goes wrong. And you really don't need vgimport UNLESS you don't have alternate links or it does blow up on you.

HTH,
Jeff

[Duncan Edmonstone]

No, sorry I don't buy what the EMC engineer is telling you here. If you are replacing a switch, and the domain ID of the new switch is set to the *same* value as the old one, and the storage is plugged into the *same* port on the switch (and therefore receives the *same* FCID), then the hardware path should remain unchanged, and therefore have the same device files.

If it were a different type of switch, with a different domain ID, and the storage were plugged into a different port, then yes you would have to go through the whole vgreduce/vgextend scenario.

Seems to me like the EMC engineer is trying to pass the hard work onto you.

Or am I missing something?

HTH

Duncan

[Jeff Schussele]

No Duncan you're not missing anything.
It's just that there's a *lot* of ands in there & it's been my experience that almost all the time I end up with new devices. Maybe it's just our storage people - but I always count on getting new devices. Whether it's a new switch, a new GBIC connection on the array or a new array altogether - I get new devices.

Rgds,
Jeff

[Ashwani Kashyap]

Its true , in my experience , even if you replace the switch with the same kind , set the same domain id and connect the cables to the same ports , majority of the time I have ended up with new devices .

Theoretically it should not happen , but with the new switch comes a different WWN of the switch , a different name servers , reload the zone sets and even if the end to end WWN are still the same , I have ended up with different devices addreses .
Some of them also were firmare issues.

Its better to be prepared for the worst .

[Don Spare]

Thank you all for you input. I will consider your responses to use in my situation.