shared disk with different /dev/dsk path on each node,

[Matthew Pegge_1]

I'm trying to recover our service guard cluster for DR purposes, but when the systems came up they both see the EMC shared disk as diffent hardware paths. /dev/dsk/c22... and /dev/dsk/c11... how can I change this?

[Sanjay_6]

Hi,

If you have identical hardware, you can change the instance number at which you see the controller and disks. Take a look at this link from itrc which tells how to change the instance number,

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000067424466

The itrc doc id is KBAN00000795.

Hope this helps.

Regds

[Victor Fridyev]

Hi,

AFAIK, there is not a problem for SG to work with shared device which has different HW path on clusterc nodes. SG scripts work with volume groups/logical volumes. So, when you export/import shared volume groups, build them accordingly. I mean, if vgshared is built on node1 with /dev/dsk/c22.., import it on the other node from /dev/dsk/c11... etc.

HTH

[Luk Vandenbussche]

There is no problem to use different names of device files. It is easier to customise your own device files.

F.E. create a file /tmp/infile to create a c35txdy

0/4/1/0/4/1 ext_bus 35

Execute the following command afterwards

ioinit -f /tmp/infile -r

The server reboots with this instruction

[Stephen Doud · Accepted solution]

Serviceguard doesn't care what path the disks are seen at... LVM does. LVM only needs to map disk paths to the correct VG. Thus, whether the disk paths match between servers is irrelevant to LVM, though humans prefer matching the paths for ease of use.

If volume group map files exist, and contain the VGID at the top, "vgimport -s" may be used to load /etc/lvmtab with the correct disks representing the volume group - regardless of the path on which they are found.

If you still desire to match disk paths between servers, previous responses cover that.

-StephenD.

[Geoff Wild]

Names of device files don't really matter - except for documentation.

What could be causing this, is your DR hosts already/or at one time had a device on that particular device file - you should clean up your devices files prior to the DR test - using rmsf

Rgds...Geoff

[Matthew Pegge_1]

Thanks