Operating System - HP-UX
1753259 Members
5645 Online
108792 Solutions
New Discussion юеВ

Re: Changing device paths to SAN luns

 
SOLVED
Go to solution
Tim Hempstead
Frequent Advisor

Changing device paths to SAN luns

We are currently migrating our SAN disk from an old infrastructure to a new one.

Currently we are making use of a HDS 95xx disk array unit which given our SAN structure give us 4 paths to each lun which are registered into each of the volume groups primary and alternate paths using normal HPUX LVM.

Now the first stage of the migration involves reconnecting the vPar to a new SAN switch and then through IBM SVCs back to the Hitachi disk. Now the content of the LUNs will still be the same but the hardware paths will change.

We were wondering what is the best way of dealing with this change in hardware paths, given that we have many LUNs and quite a few volume groups involved.

Ways we have been considering are using vgexport and vimport with map files but this could be complicated by needing to identify which of the luns is which on the new hardware paths. Another option would may be using vgscan.

Does anyone have any input on this and any input on any pitfalls we should try to avoid...?

Cheers

Tim
4 REPLIES 4
Pete Randall
Outstanding Contributor
Solution

Re: Changing device paths to SAN luns

Tim,

Use the -s option of the vgexport and vgimport commands. With it, you do not need to specify the device files - it scans and finds the disks belonging to a particular VG.

Before import:

mkdir /dev/vg??
mknod /dev/vg?? c 64 0x??0000
vgimport -s -m /tmp/vg??map /dev/vg??
vgchange -a y /dev/vg??

By the way, if you used standard lvol names (lvol1, lvol2, etc), you won't need a map file.


Pete

Pete
Alzhy
Honored Contributor

Re: Changing device paths to SAN luns

EZ..

mkdir /.dr
for vg in `/usr/sbin/vgdisplay -v|grep "VG Name"|awk '{print $NF}'`;do
vgname=`echo $vg|awk -F\/ '{print $NF}'`
/usr/sbin/vgexport -s -p -m /.dr/${vgname}.map $vg 2>/dev/null
done

This will create a map file with VGIDS of all your LVM Volume Groups. This can be part of your regular (weekly?) maintenance script. We uses to do this when our storage was exclusively managed by LVM (of course we're now VxVM and we no longer have to contend with device paths and changes)

Apart from the above and before SAN work is done. Do account for all your disks.. a simple disk count will do. (ioscan -kfnC disk)

Then, after the SAN work is done and you're booted off your OS:

1. First check that you still have the same number of disk (LUNS) from your SAN

2. Commence on "importing" your VGs as follows:

For each VG:

vgexport /dev/vgXX
mkdir /dev/vgXX
mknod /dev/vgxx/group c 64 0xNN0000
(NN must be uniq)
vgimport -s -m vgXX.map /dev/vgXX
vgchange -a y /dev/vgXX

End For


Hakuna Matata.
John Guster
Trusted Contributor

Re: Changing device paths to SAN luns

vgexport/import is the way to go. Before your mount the files system, run fsck -F vxfs -y -o nolog,full /dev/vgxx/rlvoly. Cheers.
Wessam Aly
Frequent Advisor

Re: Changing device paths to SAN luns

I have not worked on HDS before, so I dont know if you can get unique LUN IDs. you can try the following:

1) compile a little utility that comes with HPUX called scsi_io

cc -o scsi_io /usr/contrib/src/scsi_io.c

2) run this utility against any one of your dsk devices

./scsi_io /dev/dsk/c#t#d#

output should look something like this:
The thing claims to be: \
HP OPEN-E*2 011804007E0C0384 1H


generally, the first column is the array brand name, second is the type/model of the lun and third is the firmware level+the LUN ID

you can collect the data of the third column for all the disks in each VG you have.
you can then write a script to run scsi_io on all the disks the system sees after you've done your reconnections.
you can then get the mapping of dsk device files to lun ids, and use the list of new device files to do the import.
ofcourse this can all be automated with a script but it will take time and work.
usually you can rely on a vgscan of vgimport -s to do the work.
The manual said the program requires Windows 95 or better, so I installed Linux !