Finding Alternate paths

[Leon Smith, Jr]

I have a box that was built out using only one path. I would like to vgextend with the alternate path but I am unsure how to tie back the disk paths. example: disk cxtxdx path 1 would tie to disk cxtxdx path 2. please advise.

[Court Campbell]

the tXdX should be the same, just the cX would be different. example:

c35t1d0
c38t1d0

You need to do an "ioscan -funC disk" and find the two hardware paths that connect to the same disk array, and then look at the device files. once you find your other device file you can vgextend. then you could use "vgdisplay -v" to show the alternate path.

[Court Campbell]

Just to note, the t and d numbers can be used to find the LUN number on your disk array in most cases. Here are some examples:

c35t0d4 = LUN 4
c35t1d2 = LUN 10
c35t5d2 = LUN 42

You get this by multiplying 8 by the t number and then adding the d number.

[A. Clay Stephenson]

It all depends upon the type of disk array; you really can't depend on the tXdZ values being the same. A good starting point is "vgscan -p" --- this will identify alternate links. The easiest method is to shutdown your applications, umount the filesystems associated with a VG; do a vgdisplay -v > vg03.txt just to be safe; vgchange -a n /dev/vg03.

Next ls -l /dev/vg03/group and note the minor device number (e.g. 0x030000) using /dev/vg03 as an example.

vgexport -s -m /tmp/vg03.map -v /dev/vg03.

Next recreate your /dev/vg03 direcory and group file.

mkdir /dev/vg03
mknod /dev/vg03/group c 64 0x030000

vgimport -m /tmp/vg03.map -s -v /dev/vg03

This should pick up all your primary and alternate links.

You then vgchange -a y /dev/vg03 and mount your filesystems and restart your applications.

The only downside to this method is that if you wish to intentionally alternate primary and alternate links of the various PV's that comprise your VG's to better spread i/o, then you should use vgreduce to remove a primary path (making an alternate the primary) and using vgextend to add the path back as an alternate. This can safely be done "on the fly" while your applications are running.

[Angus Crome]

A simpler, although, uglier solution is to just randomly add the devices. For EMC Symmetrix, IBM Shark, HDS Lightning and HP-XP arrays, the JFS Volume Manager won't add a disk to multiple volume groups, and when it does add it to a group, the PV link is automatically created, as it finds the alternate path in that group.

For quick and dirty use only;

I would put the command into a set of for statements.

for DISK in `ls /dev/rdsk/c* | grep -v `
do
for GROUP in `ls /dev/vg* | grep -v `
do
vgextend /dev/${GROUP} /dev/rdsk/${DISK}
done
done 2>&1 > /var/tmp/output.all


This will run through the entire list of disks and volume groups adding any disks you don't specifically exclude. When you are done, you can go about cleaning up.

This works pretty well, when you don't leave a lot of un-used disks on your system. If you do have them, you should exclude them in the beginning, or look for those devices that have no LV extents associated and remove them from their respective VG.

You can then vgreduce the primaries and re-vgextend them, in order to shift the IO between paths (somewhat).

Note: It generates errors for every disk it cannot successfully add to a volume group, so I try to re-direct them to a file.

I am not saying this is a good practice, but it does generally work pretty well.