Hardware path changed when SAN switch changed

[Thayanidhi]

Hi,
Three hp-ux servers were connected to IBM SAN (ESS) through single IBM SAN switch(model: 2109/F16). Now SAN Admin want to replace the switch with dual switch for redundancy. After connecting the switches, all the hardware path to SAN disks are changed and new device files are created,
Resulting the VG did not activate. SAN Admin claims there is no configuration
in the switch and are identical/transparent. I also tried to connect the
new switch as it was in the old switch (single switch config, with same cables connected to same port), but still the hardware paths different. Now the only way to bring back the VG is, vgexport and vgimport. Is there any special procedure to replace SAN switch in hp-ux environment? Is hp-ux to be reconfigured whenever the SAN switch is replaced? See eg. below
The old hardware paths were: 1/0/2/0/0.1.16.0.36.0.0
The new hardware path is: 1/0/2/0/0.1.0.0.36.0.0
The fifth octect from right is changed. I believe it is port number where the IBM
ESS connected to. If I change the cable the path also changes.
Both switch configuration is same. But the old switch port was 16,17,18,19.
In the new switches it is port number (i.e. 0 -15).
I connected back to old switch in the same old way.
Can some one explain this number changes eventhough same model
switch is installed?

Thanks in advance.

T.Thayanidh

[Pete Randall]

You can either vgexport/vmimport or try vgscan after the switch change.


Pete

[Bernhard Mueller · Accepted solution]

The port# number shows up in the HW path and if there is a difference you get new decive files...

The ONLY way you can take care of that in a decent fashion is vgimport/vgexport.

You have this problem e.g when exchanging the Brocade SW2800 switches with newer ones. The 2800 also show port# as (16+port#) in the HW path while newer switches show port# in HW path.

Regards,
Bernhard

[Stuart Abramson_2]

Rougly, here is an example, below.

But the bottom line is, as mentioned above, that if you change the connection path, be prepared to vgexport/vgimport or vgscan.


|---------------> Protocol type
| |------------> Area
| | |---------> Port ID
0/8/0/0.3.23.42.0.0.0
| | |--> Lun: 3 bits for LUN from 0 to 7
| |----> Target: 4 bits for target from 0 to 15
|------> Bus: 8 bits but it uses only 4 upper bits for bus

In general, we have for example: (terminology)

0/8/0/0 --> This is HBA address (Host Bus Adapter)
3.23.42 --> Fibre channel Path has 3 decimal fields
0.0.0 --> Virtual SCSI-2 has 3 decimal fields

[Thayanidhi]

Hello,

Thanks for the responses. The old & new switches identical. Even the
formware level, ..etc.
Old switch is given hardware path number 16+port#.
The new switch is shown as Port#.

What is the reason?
If only vgexport/vgimport is the solution, Every time when switch
replaced(not going to be often), hp-ux need to be reconfigured?
Strange. Can some tell exactly why the port number are different?

Thanks in Advance.

T.Thayanidhi

[Massimo Bianchi]

Hi,
what are the domain id of the switches ?

I think to remind that the domain-id is involved in the numbering of the disks, but i'm not sure.

HTH,
Massimo

[Massimo Bianchi]

Hi,
what are the domain id of the switches ?

I think to remind that the domain-id is involved in the numbering of the disks, but i'm not sure.

HTH,
Massimo

[Steven E. Protter]

I feel your pain.

We have ONE SAN switch. The SAN administrator supposedly set up identical configuration for three rp5450 servers to access shared disk.

There are 30 possible LUN's available to us on the SAN.

The path on ioscan -fnC disk is identical, yet on one server its /dev/dsk/c6t8d0 and on the other its /dev/dsk/c5t8d0

I just checked it again.

Each box has two fiber cards and currently we're not using PVLINKS and its the top card owning the disk.

A real read scratcher.

It must have something to do witht he SAN.

SEP

[Thayanidhi]

Hi Massimo,

The domain id of the switches are 1, and it's not changed
in the new switch too.The problem is port number,
which is part of the hardware path.

Hi SEP,

That reminds me, that this systems are in a cluster.
The cluster already configured a SAN disk for lock disk.
I am not sure I will get the same controller instance
for the lock disk again!!

VG - Configuration can be done easily.

If instance number changes then it's a pain to synchnize
using lengthy procedure (ioconfig).

Still I hope some storage expert will clarify why the
port numbers are different.

Thanks in advance

T

[Bernhard Mueller]

Strange situation,
if you really have the SAME switch with the SAME firmware, there should be no difference, at least that is what anybody would assume.

Now that you have one of the disks as a cluster lock disk you have a real problem, until you can get a cluster downtime to change the lock disk you COULD try to rmsf the old device file and create a soft link to the new disk device file in order to eliminate your SPOF which you now have - no warranty for that however...

A better solution could be to use cminitlock,
but I do not know whether you can use it to "switch" the lockdisk. I know it is used, if you need to replace the lockdisk while the cluster is up.

Regards,
Bernhard