Migrating lvols

[Mike Hassell]

Fellow HP-UXers,

I'm faced with a dilema with installing a second DLT8000 drive in our SureStore E 2/20 DLT library unit. I'm currenty using all our HSC slots with other devices (EMC disks, GbE NIC, FWD SCSI) and I can add no more to this box, as the K370 doesn't offer more than 3 HSC slots, this is where my problem comes in. I'm forced to move the EMC disks off the core I/O card's HSC SCSI interface to an extra HP-PB SCSI interface, freeing up the slot for the additional tape drive.

This box is primarily used for a Sybase database, which is spread all over raw lvols in various volume groups. So if I take the EMC disks and move them to the PB card this will reorder the devices and hence cause problems with the existing data that is there. What are my options here? I figure we can back everything up and restore the database from the dumps once I've recreated all the lvols, but this seems rather inefficient as the data that resides on these disks still remains the same. What would be the best method to keep everything as it is now, but just swap the contoller that the disks are on?

Thanks,
Mike

[James R. Ferguson · Accepted solution]

Hi Mike:

If you device files are going to change, 'vgexport' and 'vgimport' your volume groups. Consider this, using vg02:

# vgchange -a n /dev/vg02
# vgexport -m /tmp/vg02.mapfile -v -f /tmp/vg02.oldpaths /dev/vg02

...then...

# mkdir /dev/vg02
# mknod /dev/vg02/group c 64 0x020000
# vgimport -m /tmp/vg02.mapfile -v -f /tmp/vg02.newpaths /dev/vg02
# vgchange -a y /dev/vg02

You can capture the "oldpaths" when you export the affected volume groups, edit the device declarations to reflect the new devices, name the editted file "newpaths" and import the volume group.

Regards!

...JRF...

[Sanjay_6]

Hi Mike,

Alongwith the steps outlined by JRF, work in tandem with the EMC engineer. EMC migration from one channel to another on the server may be a tricky problem.

hope this helps.

Regds

[S.K. Chan]

I have one option you can consider, of course the choice is totally up to you..
When you move the disks to another controller, the Instance number will change hence getting new device files, etc ... well you can tell the system not to change the instance number after you physically move the disks. I'm attaching the doc on how to do that. You have to be very comfortable to do this. If not sure just ignore my suggestion.

[Roger Baptiste]

Mike,

You can also do this to
avoid tracking the changed
pv names:

ll /dev/*/group >/tmp/group

vgexport -p -v -s -m vgxyz.map vgxyz
-> this will create the
vg map with the VGID in it.
Use the map vgxyz.map created
from this step for the vgimport.

Then,
Then, do a
vgexport -m /tmp/vgxyz.mapxx vgxyz
(you need to do this to actually export the VG, since the first command was run with preview option).

after the change of hardware,
do
mkdir /dev/vgxyz
mknod /dev/vgxyz/group c 64 0xnnnnn
vgimport -s -v -m vgxyz.map vgxyz
(no need to specify disk paths).

Remember this will not
give you the correct primary/alternate settings.
But, you can change it anytime
after getting the VG''s enabled.

Also, if this conenction
goes through a switch to the EMC , make sure to involve
the admin of that, along with
the EMC engineer in the process.

-raj

[James R. Ferguson]

Hi (again) Mike:

Two comments based upon others comments.

1) The primary and alternate links to your physical volumes can be setup in "one-shot" using the method I first suggested. The 'newpaths' file defines them (P1, A1, P2, A2, etc. in the order you want them declared).

2) I have changed instance numbers before. I consider the proposal to do so, "gutsy" and unnecessary.

Regards!

...JRF...

[Deshpande Prashant]

Hi
I would prefer to use vgexport/import way.

# vgchange -a n /dev/vgXX
# vgexport -m /tmp/vgXX.mapfile -v -f /tmp/vgXX.OLDPATH /dev/vgXX
Also keep the copy on EMC utility inq.

After swaping the fiber cards, use again the inq utility to get new paths and relate the old h/w path with new h/w path.

Copy the vgXX.OLDPATH as vgXX.NEWPATH and then modify the /tmp/vgXX.NEWPATH file to reflect new device files.

# mkdir /dev/vgXX
# mknod /dev/vgXX/group c 64 0x0a0000
# vgimport -m /tmp/vgXX.mapfile -v -f /tmp/vgXX.NEWPATH /dev/vgXX
# vgchange -a y /dev/vgXX

HTH
Prashant.

[Mike Hassell]

Just a follow up to this one.. I've got majority of this down and I'm ready to start this task this weekend I'm wondering the best route for idenifiying the physical disks after the device files have changed. I assume that once I move all these disks to the new SCSI controller that the only thing will change is the "cXt0d0", where X represents the controller number. So when I edit my "vg0x.newpaths" I will change the controller number and I'll be set, but to be 100% sure I was going to gather all the serial numbers of the drives in 'xstm' to ensure I made the correct changes, but since they are EMC disks it won't give me but a few serial numbers as it's really a hypervolume and not real physical disks.

Is there anyway to identify the disks after the device files have changed, or should I just bet on the fact that the cXt0d0, will change to reflect the new controller number? I have in my procedures to use 'ioscan -funC disk' to determine the new device files, but I want to be 100% sure on the device mappings that I will be manually editing. Any thoughts on this? Thanks.

-Mike

[A. Clay Stephenson]

This is correct Mike; only the instance the 'c' portion will change. One way to avoid this problem ever again is to use a level of indirection. Let's suppose that Sybase currently expects /dev/rdsk/c3t6d0 for one of its volumes/files. If you had originally used the name /sybase/vol1.dat (or some such) as that name, you could then doi a symbolic link to the actual raw device. e.g. ln -s /dev/rdsk/c3t6d0 /sybase/vol1.dat. That way, no matter what, you simply remove the old symbolic link and create a new one and you are back in business. This same logic also applies to logical volumes as well. It then becomes very easy to move thinks around should the need arise.

Food for thought, Clay