vgextend with 11.31 native pathing ques..

[Chris Fadrowski]

I have 11.31 hpux running and with this version multi-pathing is supported natively. I am connecting up a bunch of luns my Hitachi SAN. When i do a ioscan i can see both sets of disks that i zoned thru the switch. Both HBA's show up just fine.

I am using LVM to create the disks, but with the new version of HPUX should i vgextend the original disk to its companion disk down the other controller? is that needed? When i used Hitachi's HDLM, i had to. Just don't know how this works with HP's embedded multi path. please help.

[Steven E. Protter]

Shalom,

Can I see some output:

ioscan -fnC disk

I would be consistent with my vgextend, and use the same controller for all.

I believe if there are two built in paths they will both work.

I would test with a cable unplug before going production.

SEP

[Chris Fadrowski]

disk 28 0/0/14/1/0.182.0.0.0.0.0 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c12t0d0 /dev/rdsk/c12t0d0
disk 29 0/0/14/1/0.182.0.0.0.0.1 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c12t0d1 /dev/rdsk/c12t0d1
disk 30 0/0/14/1/0.182.0.0.0.0.2 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c12t0d2 /dev/rdsk/c12t0d2


----------- other path

disk 4 1/0/6/1/0.110.0.1.0.0.0 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c10t0d0 /dev/rdsk/c10t0d0
disk 6 1/0/6/1/0.110.0.1.0.0.1 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c10t0d1 /dev/rdsk/c10t0d1
disk 7 1/0/6/1/0.110.0.1.0.0.2 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c10t0d2 /dev/rdsk/c10t0d2


i have LVM'd the disks using the c10t0d0-1-2

i am wondering if i have to vgextend to the 2nd path of c12t0d0-1-2

[Michael Steele_2]

Hi:

Sounds like a problem that I've run into before, but it's specific to power path or whatever redundent pathing application Hitachi is using, and, pv links, the displaying of primary and alternate paths in vgdisplay.

So start with vgdisplay -v and verify alternate and primaries. Are they there? If not, then they also won't be in /etc/lvmtab, but verify with "...strings /etc/lvmtab...". Are they there?

Finally, you have to know ahead of time that you have primaries and alternates before you vgextend the alternates into the vg. The O/S is smart enough to know if the lun is already a part of a vg, the info is written on the lvm header which is created with the pvcreate commmand.

WARNING: Don't pvcreate -f and force a pvcreate. You shouldn't have to. Just beware that alternates already have data.

[Chris Fadrowski]

There in lies the issue. IN the old days, i had to vgextend to the c12t0d0 lun. I never had to create the actual disk in lvm. Never did a pvcreate on it.

i just did

pvcreate -f /dev/rdsk/c10t0d0
mkdir /dev/vg10
mknod /dev/vg10/group c 64 0x0a0000
vgcreate vg10 /dev/dsk/c10t0d0
lvcreate -F 100000 -n lvol110 vg10
vgextend vg10 /dev/dsk/c12tod0 **********

newfs
mkdir /b10
vi etc/fstab
done

[sujit kumar singh · Accepted solution]

Hi


11iv3 native multipathing shall be working by default even if you use persistent DSFs or the legacy DSFs.
So you need not do a vgextend to the alternate paths.


It is there inbuilt, you need to disable this explicitly for the legacy DSF if you do not wish using this.

Also suggest you to have the latest patches for LVM and Latest QPK,HWEnable and Feature11 installed.

regards
sujit

[kevin_m]

I suggest using the Agile device files for these disks. In other words vgcreate /dev/vgXX /dev/disk/diskXX instead of /dev/dsk/cXtXdX. You won't be able to vgextend any alternate paths because 11.31 will know it's the same disk. The multipathing will happen automatically as mentioned above unless you disable it on a per-LUN basis.
- Kevin