vPars in nPar - moving SAN boot disk

[Duncan Edmonstone]

Hi,

Just about to make some major changes to a SAN (switch upgrades) which will most likely effect the HW paths of all my disks (& tape) devices including my SAN boot disks. I'm comfortable with most of what is involved on standard systems (and nPars). However we have 1 superdome nPar with several vPars in it, all of which boot off the SAN. My (abridged) process for the non vPar systems goes something like this:

1. ensure all access is via primary paths
2. vgreduce secondary paths out of root vg
3. move/upgrade/replace switch ports for secondary paths
4. ioscan/insf to get new devices
5. vgetend new pvlink back into root vg
6. check lvlnboot etc., update alt boot path using setboot.
7. reboot using alt boot path
8. repeat items 1-6 for pri boot path
9. reboot using pri boot path

What steps (if any) do I need to change/add to handle the vPar'd partitions?

Points for good (detailed) answers - particularly if you've done this yourself

Cheers

Duncan

[harry d brown jr]

Duncan,

If your boot disks path changes, then you will have to modify your vpar db to reflect it. The other IO paths will remain the same because they don't drill down to the disk device, they just reflect the IO card.

You might want to vgexport any non-vg00's and keep a map of the vg in case you need to change the disk devices.

After the SAN change, you will need to boot one partition WITHOUT vpars running so you can determine what device is what so you can make the appropriate changes in the vpar db if necessary.

I usually run these commands before messing with my vpars, printing and saving them on my PC for future reference:

print_manifest
ioscan -fn
vgdisplay -v vg*
bdf
vparstatus -v
vparstatus -A
mount


Modifying a SAN sucks, and we have done it three times already. It seems no matter how much effort you put into the design, something always slaps you into changing it.

good luck!

live free or die
harry

[Duncan Edmonstone]

Thanks Harry,

Having done a little more research now, I can't see why I need to boot without vpars? The reading I have done leads me to think I can effectively treat each vpar the same as a 'standalone' system, simply using setboot to change my paths as I make the changes described in my original post, and this updates the vpar database appropriately. The only issue is then with updating stable storage for the npar , which presumably I can either do from BCH or using the parmodify command?

Or does vpmon need to actually access the disk it was booted from after it has been loaded into memory? (doesn't it just send all its updates to the vpard daemons in each vPar?)

Any more input greatly appreciated...

Thanks

Duncan

[Duncan Edmonstone]

ping...

Still looking for a more detailed answer here...

Thanks

Duncan

[harry d brown jr]

Having done a little more research now, I can't see why I need to boot without vpars?
>>> I guess I'm a little cautious.

The reading I have done leads me to think I can effectively treat each vpar the same as a 'standalone' system, simply using setboot to change my paths as I make the changes described in my original post, and this updates the vpar database appropriately. The only issue is then with updating stable storage for the npar , which presumably I can either do from BCH or using the parmodify command?
>>> yes the setboot will work, but I'm not sure about using the BCH to modify the npar stable storage without having to reboot. My brain is fried today :-(

Or does vpmon need to actually access the disk it was booted from after it has been loaded into memory? (doesn't it just send all its updates to the vpard daemons in each vPar?)
>>> I believe it (vpmon) needs access to the disk it started from, but then again I have never yanked the disk from the system while the system is running.


live free or die
harry

[Duncan Edmonstone]

Just thought I'd let you know, a call logged with HP confirmed that I can indeed remove the disk vpmon booted from, as long as the vpar also on that disk has been stopped. The important thing to remember however is that when next starting vpmon, to boot it off the partition which was last in use, as this will have a more up-to-date vpdb.

Cheers

Duncan

[Alzhy]

Duncan,

As a prep step on your nPar with vPars, make a backup of the map file with VGID's of your root VG's on each vPar. Also make a backup of your VG00 mapfile of the "nPar" you usually boot VPMON off. Also disable any and all application startups and non VGOO mounts on this nPar OS disk.

Come "changement" day:

1. shutdown all vPars until you're at the MON prompt
2. Have your SAN folks do there thang..
3. Power up the nPar, halt bootup so you are at BCH .. take inventory of the available bootpaths which will give you an idea if your FC bootpaths have changed and what there new PATHS are.
4. If the VPMON bootdisk (your nPar's boot disk really) is still on the same FC path.. then go to step 6 if not do step 5.
5. boot LVM maintenance mode (boot -lm) and fix your nPar (or VPMON disk).. boot your first vPar off this VPMON disk.. fix vPar bootpaths accrodingly (vparmodify command)
6. If the other vPar's bootdisk FC Paths have changed then you simply boot each vPar in to LVM maintenance mode and fix VG00 so its component SAN disks are onits correct paths (this is just a matter of simply exporting, recreating VG00 dev directory and importing using the map file earlier...

to boot a vPar from another vPar in LVM maint mode:

vparboot -p vparname -o "-lm"

That's it...

[Alzhy]

And yes .. I've done this myself.

Am using EVA 5000 LUNS as boot/dump on my SecurePath 3.0D managed 11i rp8400/8420/SD systems.

[Duncan Edmonstone]

Thanks Nelson - I was already clear on these points, but always good to hear someone else has done it successfully.

We move 3 npars 1 npar with 4 vpars and 3 standalone systems on this Sunday - wish me luck!

Duncan