Howto identify alternately pathed disks prior to vgextend?

[Ralph Grothe]

Hello,

today I have been provided with alternate paths of disks subsystem disks by our SAN admin.
Now I hesitate to really execute the

vgextend vg?? /dev/of/alternate/path

although I'm pretty confident to guess the correct devices.

Is there a way to make sure to have picked the right device file, or will vgextend moan anyway if it wasn't so?
In the manpage of vgextend it only says that a new attribute like "alternate" will appear for the added PV.
Well, I would like to avoid picking a wrong device that although it doesn't already belong to another VG (in that case I guess vgextend would complain) just happened to have been unassigned yet.
Ok, it wouldn't be much fuss to do a vgreduce if "alternate" didn't show up, but I'm not fond of the trial and error method.
I thought a consecutive verbose diskinfo on both device files for the deemed identical disks would reveal something like a unique ID,
but that's not the case.

Rgds.
Ralph

[Naveej.K.A]

hi,

c0t4d0 and c1t4d0 are one and the same

and

c5t13d3 and c4t13d3 are the same

the controller number only varies....the rest all remains the same.

that is what my logic says

regds
Naveej

[Dietmar Konermann]

Ralph,

you may compare the PV's unique ID which is part of the LVMREC. This is what actually vgextend does to detect alternate paths.

# echo "0d8200?UY" | adb /dev/dsk/xxxxxx

Best regards...
Dietmar.

[Sunil Sharma_1]

Hi,

There is no direct way to know about alternative link. If you are using SAN like EMC then EMC command inq will give you this information.

In general we should trust storage admin for these information.

here are few old threads for same.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=340046

Sunil

[Geoff Wild]

There is an easy way - if your SAN is on EMC, then issue a syminq (should be in /usr/symcli/bin/syminq).

/dev/rdsk/c31t4d5 M(4) EMC SYMMETRIX 5670 651E7000 35354880

is the same disk as:

/dev/rdsk/c33t4d5 M(4) EMC SYMMETRIX 5670 651E7000 35354880

as both are EMC disk 1E7

If not on EMC, then I'm sure there must be some command you can run that comes with your SAN - talk to your SAN Admin.

Rgds...Geoff

[Ralph Grothe]

Dietmar,

cute hack, but it only seems to distinguish the type of disk?

See the first two are the root/boot disks, the last two assumed alternately linked same disk:

# for c in 1 2 7 10;do echo 0d8200\?UY|adb /dev/dsk/c${c}t6d0;done
2008: 698319322 2001 Apr 22 05:52:45
2008: 698319322 2001 Apr 22 08:43:34
2008: 690319332 2003 May 28 16:02:45
2008: 690319332 2003 May 28 16:02:45


Not much difference in the first two, that indeed are laternate boot path but referring to different disks.

[Ralph Grothe]

Sunil, Geoff,

I'm afraid, I think we relinquished our EMC.
So the disks attached come from a HITACHI box, e.g. according to adb example above

# for i in 160 250;do ioscan -knfCdisk -I $i;done
Class I H/W Path Driver S/W State H/W Type Description
===================================================================================
disk 160 1/0/0/0.98.13.19.0.2.2 sdisk CLAIMED DEVICE HITACHI OPEN-9
/dev/dsk/c7t2d2 /dev/rdsk/c7t2d2
Class I H/W Path Driver S/W State H/W Type Description
====================================================================================
disk 250 1/2/0/0.119.34.19.0.6.0 sdisk CLAIMED DEVICE HITACHI OPEN-9
/dev/dsk/c10t6d0 /dev/rdsk/c10t6d0


I will talk to our SAN admin for an extra lesson, but in general I think I can trust them.

[Ralph Grothe]

Well, probably I have only been ventilating pseudo problems here.
I had the guts to issue the vgextend, and LVM correctly detected the alternate links.

# vgdisplay -v vgdat5|sed -n '/--- Ph/,$p'
--- Physical volumes ---
PV Name /dev/dsk/c7t5d4
PV Name /dev/dsk/c10t5d4 Alternate Link
PV Status available
Total PE 880
Free PE 0
Autoswitch On

PV Name /dev/dsk/c7t5d5
PV Name /dev/dsk/c10t5d5 Alternate Link
PV Status available
Total PE 880
Free PE 0
Autoswitch On

[Dietmar Konermann · Accepted solution]

Ralph,

the PVID consists of 8 bytes. The 1st 4 bytes contain the machine id (uname -i) of the system where pvcreate has been run. The latter 4 bytes are the timestamp.

So, in your example there is indeed a difference between the 1st two disks... they have a different timestamp. :-) The id _and_ the timestamp need to be identical for alternate paths.

Best regards...
Dietmar.

[Ralph Grothe]

Ok, LVM seems clever enough to handle a whole bunch in one go, which makes things easily scriptable.

# vgextend vgdat3 $(vgdisplay -v vgdat3|awk '/PV Name/{print$NF}'|sed 's/c7/c10/g')
Volume group "vgdat3" has been successfully extended.
Volume Group configuration for /dev/vgdat3 has been saved in /etc/lvmconf/vgdat3.conf


# vgdisplay -v vgdat3|grep PV\ Name
PV Name /dev/dsk/c7t2d6
PV Name /dev/dsk/c10t2d6 Alternate Link
PV Name /dev/dsk/c7t2d7
PV Name /dev/dsk/c10t2d7 Alternate Link
PV Name /dev/dsk/c7t3d0
PV Name /dev/dsk/c10t3d0 Alternate Link
PV Name /dev/dsk/c7t3d1
PV Name /dev/dsk/c10t3d1 Alternate Link
PV Name /dev/dsk/c7t3d2
PV Name /dev/dsk/c10t3d2 Alternate Link
PV Name /dev/dsk/c7t3d3
PV Name /dev/dsk/c10t3d3 Alternate Link
PV Name /dev/dsk/c7t3d4
PV Name /dev/dsk/c10t3d4 Alternate Link
PV Name /dev/dsk/c7t3d5
PV Name /dev/dsk/c10t3d5 Alternate Link
PV Name /dev/dsk/c7t3d6
PV Name /dev/dsk/c10t3d6 Alternate Link
PV Name /dev/dsk/c7t3d7
PV Name /dev/dsk/c10t3d7 Alternate Link
PV Name /dev/dsk/c7t4d0
PV Name /dev/dsk/c10t4d0 Alternate Link


Dietmar, your right the time stamps of the boot disks do differ indeed.

Is the knowledge of the Bytes' meaning public folklore, or is it avidly kept secret by a few HP gurus (i.e. some official docs available?)

[Dietmar Konermann]

At least the LVM chapter of your Software Recovery Handbook should contain that information.

[Ralph Grothe]

Ah Dietmar, forgot to ask.

So far our SAN admin only provided alternate paths to two of three cluster nodes (depending on premises of servers).
So I can only do a vgexport and vgimport of new LVM meta data (about new paths) on only one of the other nodes.
Will this impair cluster functinality (more than it has been uptil now)?

[Dietmar Konermann]

No problem to have different path setups on different cluster nodes. OK, there should be at least 1 path (better 2) for each PV. :-)

[TwoProc]

I use the following script to SEE what the id is on a disk. I'm using an XP512, and I figured it out a while back using "od". This works great for me. This isn't HP approved, I figured it out myself, so PLEASE make sure that what you're seeing is what you expect to see, and makes sense - by cross checking with other tools mentioned earlier in the thred. I use this because I find that the xpinfo tool can be misleading at times. So, I use this as a cross-checking tool - as I advise you should do, not as a primary tool...

Be sure to understand that this should give you an idea if you have the same PV, NOT whether or not you are using the same disk...
(just making sure we're all on the same page).

#
# @(#) get_pv_id - get the unique id of a physical volume
#
#
if [ $# -lt 1 ]; then
echo "ERROR- no physical volume given"
echo "ex. get_pv_id c10t2d4"
echo ""
exit 1
fi
if [ -x /dev/dsk/$1 ]
then
od -N 20000 /dev/dsk/$1 | head -3 | tail -1 | cut -f 10 -d " "
else
echo "ERROR- invalid physical volume given"
echo "ex. get_pv_id c10t2d4"
echo ""
exit 2
fi