Alternate links says NO_HW

[Josep Arques T.]

Hi

our SAN team has told us that a switch connecting our server to the SAN disks is to be replaced with a new one.
That means we have to modify all VGs in order to remove all PV links related to that switch.

The problem is we have found some cases where the alternate link is not working correctly as shown above.



ioscan says


disk 120 1/4/0/0.52.13.255.0.0.4 sdisk NO_HW DEVICE HITACHI DF600F
/dev/dsk/c14t0d4 /dev/rdsk/c14t0d4
disk 121 1/4/0/0.52.13.255.0.0.5 sdisk NO_HW DEVICE HITACHI DF600F
/dev/dsk/c14t0d5 /dev/rdsk/c14t0d5



ammdbp02:/root>vgdisplay -v vgduna

.....

PV Name /dev/dsk/c15t0d4 <----------------------- to be replaced soon
PV Name /dev/dsk/c14t0d4 Alternate Link <----- NO_HW
PV Status available
Total PE 6783
Free PE 0
Autoswitch On

PV Name /dev/dsk/c15t0d5 <---------------------- to be replaced soon
PV Name /dev/dsk/c14t0d5 Alternate Link <----- NO_HW
PV Status available
Total PE 6783
Free PE 3791
Autoswitch On

......


I'm looking for a good procedure to fix the problem before the switch is replaced.

If the SAN connection is ok, would it be correct to do something like this?

vgreduce /dev/vgduna /dev/dsk/c14t0d4
vgreduce /dev/vgduna /dev/dsk/c14t0d5

and ioscan -fnC disk + 'insf -e' to recreate the alternate links

Thanks

[Suraj K Sankari]

Hi,
do not remove any thing 1st try

insf -e
ioscan -fnC disk

and check

Suraj

[Viktor Balogh]

>"If the SAN connection is ok, would it be >correct to do something like this?"
>
>vgreduce /dev/vgduna /dev/dsk/c14t0d4
>vgreduce /dev/vgduna /dev/dsk/c14t0d5

If you give these device files to vgreduce then you won't have any working path to your LUNs as vgreduce removes these from the LVM configuration. To be clear, you should feed the other two devices to vgreduce. (and this could be done in a single line also)

But if I were you I would just do a 'pvchange -a n' temporarily to all the paths that will be replaced, and assure that the zoning after the change remains the same.

[Rita C Workman · Accepted solution]

All I can say is...........Halto!!

The only path (switch) you have working is the one they want to replace. Do that and you will have a problem - a big one.

First, maybe the switch to be replaced is the one showing all the NO_HW and somebody is looking at the wrong switch. If you don't run your SAN than get with the person who does and confirm which switch is on which fabric going to which disk.
Could be those NO_HW actually relate to the one they are going to replace and you just got turned around.
Talk to them...communication is important.

If the one that is working for you is the one that IS to be replaced - then get them to hold up on doing that till you get the other disks showing properly and things are fixed for that path/fabric.
Again talk to the SAN folks cause it may be a connection issue on the fiber network as to why you have lost that connectivity for that second path.

Make sure you have solid connectivity down both paths before anybody removes anything.

Just a suggestion,
Rita

[Josep Arques T.]

Thanks to all, getting support from HP engineers it looks like the problem belongs to the SAN people, both HBA are working OK but one of them can't access the LUNs connecting to 2 specific ports.