LVM challenge?: booting SAN lun on different HPUX server

[Kevin_31]

One of the advantages of our data being on a SAN is we can repoint data from one machine to another quite easily. However, my knowledge of LVM is probably what's holding me back from being able to come up with a plan, especially when referring to vg00 (which is also on our SAN!).

I have a lun with the boot sector, and the rest of vg00 which has always been owned by "boxa". It was built with Ignite as it should have been.

In order for me to point that same lun at a "boxb", it'll be seen on a different hardware path, thus instead of it being found on "c5t4d0" HW path 0/3/0/0.1.18.0.0.4.0, I predict it'll be something like "c12t4d0" HW path 10/0/0.2.15.0.0.4.0.

Besides the vg information having the wrong physical data, I've also got the boot information created by mkboot, lvlnboot -b, etc.

It's like I want to rerun the last few or specific steps from an ignite to rescan the vginformation, rewrite the boot sector stuff, but I've got a little chicken-and-egg problem about fixing the boot information before I can boot.

Anyone feeling generous with your expertise? points and appreciation are ready to be dished out for any replies!

cheers,
Kevin

[Victor BERRIDGE]

Hi Kevin,
I dont quite understand what you are up to, or how is is your configuration. Are you trying to reuse on boxb the LUNs dedicated to the vg00 (on SAN) of boxa or is it a copy on another LUN?

Al the best

Victor

[Hoefnix]

Hi,

Swapping any other volumegroup is easy, but what you like to do is interesting.

I think you will have to boot from something else (disk/CDROM/Network) to be able to fix your vg-information/boot-information on the disk on the SAN-LUN.

Regards,
Peter

[Kevin_31]

Victor: reuse on boxb the LUNs dedicated to the vg00 (on SAN) of boxa

Peter: yes! I'm looking for help booting over network then setting boot options and LVM config stuff from LUN as it's seen from boxb, without destroying the OS as it was built on boxa!

Is there any documents/articles/links anyone can help me with?

[Duncan Edmonstone]

How 'different' is boxb from boxa ? Is it the same type of server just configured differently - if so, then the trick is going to be to boot the system to LVM maintenance mode where you can reconfigure vg00 to your hearts content! I've seen this done when Superdome complexes are re-configured - can't remember the details but went something like:

interrupt boot and boot off SAN disk:

boot 10/0/0.2.15.0.0.4.0

choose to interact with ISL, and at the ISL prompt:

hpux -lm

will boot to lvm main mode where you can vgexport and vgimport vg00, and then use lvlnboot to update root/boot/swap/dump information.

I expect you will find a whole host of issues with old device information in the /etc/ioconfig & /stand/ioconfig files, which will probably require playing around with ioinit to sort out.

There's probably more as well, but I've never done it myself so I'll leave it to wiser heads than mine - but that should get you started.

HTH

Duncan

[Victor BERRIDGE · Accepted solution]

Hi again,
The idea is once booted in single user, if you are happy with the old config (fs size swap etc), using command line mount /usr, /var /tmp (maybe) then go and edit / modify /etc/hosts fstab etc...
then use the set_parms command to change the hostname IPaddress etc...
I would remove the ioconfig to let the box rescan all again

I did this once but not on a san at that time: Reusing a extenal subsystem (which had vg00 on) on another box in a different location:
Boot in single user, modify all the needed files (/etc/rc.onfig.d/netconf /etc/hosts...)
renamed the /etc/ioconfig file vgexported what wasnt need
shutdown -h

tranported the subsystem to its new location,plugged and booted on it, it complained about some hardware (boxes were not quite the same -made some difference in the kernel but nothing alarming)
tested - at the second reboot, all was fine...

Good luck!
All the best
Victor

[Colin Topliss]

1. Reboot the system into LVM Maintenance mode:
If you donâ t remember how to do it, just:
Reboot system
Interrupt boot sequence
At Main Menu: Enter command > bo pri
Interact with IPL (Y, N, Q)?> y
ISL> hpux â lm

2. Once the system has booted:
# vgexport /dev/vg00
# vg_export all additional vg_groups. If you donâ t do this, if you lose lvmtab itâ s more painful to re-create.
# mkdir /dev/vg00
# mknod /dev/vg00/group c 64 0x000000
# vgimport /dev/vg00 /dev/dsk/c12t4d0
# vgchange â a y vg00
# mount â a

That will get your system back with correct entries in the lvmtab.

3. To change your boot parameters, do:
# lvlnboot â b /dev/vg00/lvol1
# lvlnboot â r /dev/vg00/lvol3
# lvlnboot â d /dev/vg00/lvol2
# lvlnboot â s /dev/vg00/lvol2

You may need to change lvol1, 2 and 3 to the relevant names if you have named lvols.
Basically lvol1 = stand
lvol2 = swap
lvol3 = root

One thing to remember - if you have a multitude of other volume groups defined, take copies of their map files (PV and LVOL) incase you have to re-create them. For each vg, do:

vgexport -p -v -f /pv_map -m /lv_map /dev/

Keep them in the root filesystem for the duration of the work - that way they will always be available incase of problems with other filesystems.

I've adapted these notes from ones I have for vgchgid'ing the root disk(s) - I've read through them, and I can't see any problems, but then again it is 01:0