Service Guard Linux Lock Disk issue

[Andrew Young_2]

Hi.

An administrator at a client has added another LUN to their SAN (a Clarion I think) and presented it to their Service Guard Linux hosts. Having rebooted the one node the disk lettering has changed so the lock disk - and just about every other disk - is now different on this node. They are getting a "Cannot reach lock device" errors on that node.

I'm sure the solution is pretty obvious, maybe I'm a few cups of coffee short of a good morning, but I can't figure it out.

Some help would be appreciated. Also any ideas on preventing this in future.

The techie stuff:
SGLX A.11.18
Redhat 4u7
HP P Series blades

Thanks in advance.

Andrew Y

[Sameer_Nirmal]

You may need to export the VGs and import them thereafter.

To prevent this problem in future, you may want to refer this

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=376220&prodTypeId=15351&objectID=c01538162

[Matti_Kurkela]

Yes, this is a fact of life in Linux SAN configurations. The /dev/sd* names are not persistent and you should assume that they *will* be changing at some point.

In Linux, it is not necessary to export & import VGs - simply running "vgscan" will re-detect the VGs.

You should use something that provides persistent names for your disk devices. There are many alternatives for that: if you use LVM, it handles this automatically. But for the lock disk, you may need a different solution.

If you don't use LVM but have multiple paths to your SAN disks, some multipath solutions will also provide persistent naming (dm-multipath certainly does it).

If you use plain /dev/sd* devices, you should write some udev rules to assign persistent names for your devices.

Please see this document about using udev with Serviceguard for Linux:
http://docs.hp.com/en/8859/udev_sglinuxconfig.pdf

MK

[melvyn burnard]

Chaps, I think you are missing something here. A Lock Lun is NOT part of a VG, so there is nothing to do with VG that may cause this issue. It is purely down th enon-persistance of devices in Linux.

[melvyn burnard]

Perhaps this might help?
http://docs.hp.com/en/8859/udev_sglinuxconfig.pdf

[Serviceguard for Linux]

Melvyn has one good point.

I don't remember the exact functions of the drivers with different versions of the FC drivers, but both have had persistent naming as a function (side effect) of their multipath. So if you are using multipath (and you should) then there may be a driver configuration problem.

[Andrew Young_2]

Hi All

Thanks for the advice.

I have tried to do as suggested but with no luck.

The /sbin/scsi_id command fails with errors when querying the disk. I suspect this is because the EMC DMX disk array is blacklisted by the scsi_id system as default. However if I run the scsi_id command with the -g -s options to get the ID I get the following:

SEMC SYMMETRIX 751545487000

I am open to suggestions on what to do.

Regards

Andrew Y