Finding alternate paths to a disk

[Olivier Masse]

Hi,

I'm looking for tricks that I could use to identify that a certain disk device has other devices that point to the same path. It can't be too manual because it must be easily scriptable.

For example, if I do an ioscan and see /dev/dsk/c1t2d3, I'd like to know what other devices in the ioscan output point to the same physical disk.

The only trick I found until now is limiting my search under a unique fiber controller but I'm looking for other ways that could be easier to script.

I can use disk vendor proprietary tools to check the serial number of the disk (such as EMC's inq). But I want ot use only standard HP-UX commands such as ioscan or diskinfo, as I am planning a disaster recovery procedure at an external site which will not necessarily have the same disk tower as mine and for which I must consider that no vendor tool will be available.

Thank you

[Massimo Bianchi]

Hi,
i think that you may use vgid and pvid to get this information.


VGID:

echo 0x2010?2X | adb /dev/dsk/cxtxdx | expand | tr -d " " | sed "s/2010:/VGID /"

This command, issued for every disk, will tell you the VGID of each disk.

Those who have identical VGID belongs to the same vg. easily scriptable.
When you do the import, lvm will recognive primary and alternate patch for you.


PVID:

echo 0x2008?2X | adb /dev/dsk/cxtxdx | expand | tr -d " " | sed "s/2008:/PVID /"

those disks that have the same PVID are the same phisical disk. esaily scriptable.


Massimo

[Pete Randall]

Olivier,

How about vgscan in preview mode: "vgscan -a -p -v"?

from man vgscan:

"If there are dual controller devices, only the
primary controller device path is scanned, unless you specify the -a
option to allow access to all paths."


Pete

[Olivier Masse]

Massimo and Pete,

The disks I will be looking at will not belong to any VG so I'm looking for other ways if possible. Thanks for the tricks anyway, as I could always check if a disk is a member of any VG prior to assigning it.

I'm updating a disaster recovery script that creates all VGs on the fly on an external site to automate commands such as vgcreate, vgextend, lvcreate, newfs and so on. vg00 will be recovered with make_recovery but the other VGs must be done the hard way. There are lots of filesystems in there and doing this manually would take hours.

This is fine when disk devices do not have multiple paths, but if they are I'm ending up trying to vgextend with PVs that are already allocated -- the lvm will not let me do that, but it's not a "clean" way to automate this.

[Olivier Masse]

Massimo,

I tried extracting PV ID and it works well.

I'll try to think of something I could do with this, maybe I can just pvcreate all the disks
in the system first hand and only keep a list of unique device names.

Thanks a bunch.

[Massimo Bianchi · Accepted solution]

Mmmh, it looks more challanging now.

Now that you know PVID, VGID, you can always test the disk before using it.

Second: create your own bundle of tools, that shall include xpinfo, syminq, inq, so you will always have them at hand for such cases.

Massimo

[Olivier Masse]

Massimo,

I looked a lot in other threads and nobody is able to do this without using LVM. And there is no way to extract a serial number from proprietary disk arrays using cstm, diskinfo and others.

So for the record, I found a way to do this using LVM.

1. For all the disks, do a pvremove to be sure they are clean (as they could have been inherited from a previous customer). At a disaster recovery site I'm using scratch disks anyway so I don't care if I zap them.

2. Then do a pvcreate on all of them, no matter if there are alternate paths or not. This will create a PVID on each of them.

3. Extract the PVID of all the disk devices using your adb hack. The devices that are alternate paths will have the same PVID. This list can help me remove those that are alternate paths, and possibly balance them between different controllers.

4. Then I can either pvremove the disks and start over or just create new VGs using these disks.

Case closed.

Thanks!