HPUX Controller Address for metas from DMX

not an issue, it's just how one box determined its controller id. For example one box might have a tape drive so it would shift the controller id by one or two. Is cluster guard already setup on this system ?

Service gaurd is already set up on these servers. but right now attached to other array disks. Data will be moved over to DMX disks and DMX disks will come to use then only.

Is there any significance of these controller address in service gaurd perspective?

VBUS contributes in determining the actual controller number .. It's right to say that changing vbus changes controller .. however I can't predict WHICH controller hpux will allocate for the new "virtual controller"

You have to dig in output of "ioscan -fnkC ext_bus" .. You'll find where is the difference between the two hosts .. Note in the output of above command that "instance number" is exactly your controller number .. Now find the culprit

Yep .. every host have its "history" (devices seen and mapped in iomapper). Can you please post output of command

ioscan -fnkC ext_bus

of both hosts ??

it's significant when you setup service guard to make sure you select the same disk on all cluster members as your FIRST_CLUSTER_LOCK_PV in /etc/cmcluster/cm_cluster.cfg, for example it could be /dev/dsk/c163t0d0 on one box and /dev/dsk/c125t0d0 on another. When it's time to migrate from one DMX to another ..cluster lock device is usually a pain the butt as you have to recompile the cluster. Although search this forum for STK posts ..apparently there is a way to trick cluster guard into using another device without recompiling the cluster.

Yes, VBUS determines the controller number.

I have same disks from same FA with same Vbus numbers on both servers. But the controller on the host sides are different. Is it ok?

the "history" file, there are times when you have to clean this file up to get HPUX to recognize new storage.

http://docs.hp.com/en/B3921-90010/ioconfig.4.html

yep .. when you reached max ext_bus number

I wrote "iomapper" .. however the right wording is "ioconfig" as you posted

a bunch of NO_HW ..you've been reclaiming stuff ?

server1# ioscan -fnkC ext_bus

Class I H/W Path Driver S/W State H/W Type Description

===========================================================================

ext_bus 0 0/0/3/0.0 side CLAIMED INTERFACE IDE Primary Chann

el

ext_bus 1 0/0/3/0.1 side CLAIMED INTERFACE IDE Secondary Cha

nnel

ext_bus 2 0/1/1/0 c8xx CLAIMED INTERFACE SCSI C1010 Ultra1

60 Wide LVD A6829-60101

ext_bus 3 0/1/1/1 c8xx CLAIMED INTERFACE SCSI C1010 Ultra1

60 Wide LVD A6829-60101

ext_bus 4 0/4/1/0 c8xx CLAIMED INTERFACE SCSI C1010 Ultra1

60 Wide LVD A6829-60101

ext_bus 5 0/4/1/1 c8xx CLAIMED INTERFACE SCSI C1010 Ultra1

60 Wide LVD A6829-60101

ext_bus 26 0/4/2/0.50.98.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 27 0/4/2/0.50.98.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

ext_bus 8 0/4/2/0.97.9.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 9 0/4/2/0.97.9.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 10 0/4/2/0.97.18.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 11 0/4/2/0.97.18.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 16 0/4/2/0.97.26.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 17 0/4/2/0.97.26.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 18 0/4/2/0.97.39.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 19 0/4/2/0.97.39.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 22 0/4/2/1.111.66.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 23 0/4/2/1.111.66.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

ext_bus 28 0/5/1/0.51.98.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 29 0/5/1/0.51.98.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

ext_bus 6 0/5/1/0.98.9.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 7 0/5/1/0.98.9.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 12 0/5/1/0.98.18.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 13 0/5/1/0.98.18.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 14 0/5/1/0.98.26.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 15 0/5/1/0.98.26.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 20 0/5/1/0.98.39.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 21 0/5/1/0.98.39.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 24 0/5/1/1.112.65.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 25 0/5/1/1.112.65.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

root@server1:/root_home #





Server2:



Server2 # ioscan -fnkC ext_bus

Class I H/W Path Driver S/W State H/W Type Description

===========================================================================

ext_bus 0 0/0/3/0.0 side CLAIMED INTERFACE IDE Primary Chann

el

ext_bus 1 0/0/3/0.1 side CLAIMED INTERFACE IDE Secondary Cha

nnel

ext_bus 2 0/1/1/0 c8xx CLAIMED INTERFACE SCSI C1010 Ultra1

60 Wide LVD A6829-60101

ext_bus 3 0/1/1/1 c8xx CLAIMED INTERFACE SCSI C1010 Ultra1

60 Wide LVD A6829-60101

ext_bus 26 0/4/1/0.50.98.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 27 0/4/1/0.50.98.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

ext_bus 8 0/4/1/0.97.9.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 9 0/4/1/0.97.9.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 16 0/4/1/0.97.18.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 17 0/4/1/0.97.18.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 4 0/4/1/0.97.26.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 5 0/4/1/0.97.26.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 10 0/4/1/0.97.39.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 11 0/4/1/0.97.39.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 21 0/4/1/1.111.96.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 23 0/4/1/1.111.96.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

ext_bus 24 0/5/1/0.51.98.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 25 0/5/1/0.51.98.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

ext_bus 12 0/5/1/0.98.9.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 13 0/5/1/0.98.9.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 18 0/5/1/0.98.18.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 19 0/5/1/0.98.18.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 6 0/5/1/0.98.26.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 7 0/5/1/0.98.26.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 14 0/5/1/0.98.39.19.0 fcd_vbus NO_HW INTERFACE FCP Array I

nterface

ext_bus 15 0/5/1/0.98.39.255.1 fcd_vbus NO_HW INTERFACE FCP Device

Interface

ext_bus 20 0/5/1/1.112.96.0.0 fcd_vbus CLAIMED INTERFACE FCP Array I

nterface

ext_bus 22 0/5/1/1.112.96.255.0 fcd_vbus CLAIMED INTERFACE FCP Device

Interface

Message was edited by:
Stefano Del Corno

The only difference I can see betwee two hosts is that server1 have 4 SCSI controllers (A6829-60101) while server2 have only 2 .. and that's why you have an offset of 2 between the hosts. Note that removing 2 scsi controllers from server1 won't fix issue since hpux records in /etc/ioconfig file association between hardware bits and instance numbers. Removing 2 scsi controllers will simply give you another pair of "NO_HW" lines in ioscan output ..

I wanted to know that having different controller address in a cluster for same disks will have any problem? I guess no from your replies ...

If you have Service Guard, no issues at all since when you configure your cluster you simply tell SG the name of your VGs and every host have its own lvmtab where the VG is associated with underlying devices. If you don't have a quorum server and use quorum devices you also have a line for every host detailing the name of the quorum device. So with MCSG no probs at all. It's suggested but not mandatory to have same names.

Keeping same C number on both the cluster hosts have been recommended/used and this method is not always practical. Keeping the same C number requires a proper planning of how each host is connected to same on the LUN. But having different C number is not at all harmful. But u cna still see the t and d numbers are same.

Interms of cluster or the cluster lock PV, the cluster configuration file has a mapping of ctd number to each hosts in the cluster. No need to have the same ctd number. But any chanages need to get updated.