Upgrading vg00 from 18Gb to 36Gb

[Jose Mosquera]

Hi Pals,
#uname -a
HP-UX mad14h B.11.00 A 9000/800 1100424677 two-user license

I'm trying upgrade my vg00 size. At present we have 2x18Gb Mirror/UX disks configured and the new vg00 configuration will be 2x36Gb Mirror/UX. At presente this vg00 have not only system files, have severals sybase raw files. I have planned make this upgrade with Mirror/UX way, the issue begins when I try add (vgextend) the new 36Gb's disk in the vg00:
#vgextend /dev/vg00 /dev/dsk/c1t0d0
vgextend: Warning: Max_PE_per_PV for the volume group (4350) too small for this PV (8683).
Using only 4350 PEs from this physical volume.

I know that in 18Gb's disks the are PE=4 and in the new 36Gb's disk are PE=8. Well, whats means exactly, Would I really lose the non grateful space? Some way to force that PE of the new disk (36Gb) at 4?

Thanks in advance.

[James R. Ferguson · Accepted solution]

Hi:

Using MirrorDisk/UX to clone your LVM geometry isn't going to change it. By this, I mean that the original limitations of the volume group's physical disks are simply replicated to the larger, newer disks. You will not be able to use the full extent of the 36GB disk.

The safest way to upgrade is to use Ignite to make a recovery tape of vg00. Use an Advanced Installation mode and your Ignite recovery tape with the 36GB disks; size your logical volumes appropriately; and rebuild your vg00.

I suggest that you first eliminate application filesystems from your existing vg00. Keeping vg00 solely for the operating system logical volumes and primary swap space makes operating system upgrades, updates, cloning and disaster recovery much easier than when you don't.

Looking forward, if you were running 11.23 or 11.31 you might have used 'vgmodify' :-)

Regards!

...JRF...

[likid0]

You need ignite for that purpose, make a backup image, and restore it in your new 36 gig disks

[Jose Mosquera]

James,

Thank you very much for you sooner answer. Well I have discused this point with my DBA and she is trying to move these raw device files to another VG. In the case that this will be possible I'm agree to proceed with an ignite procedure to upgrade vg00 size. In this order of ideas my procedure step by step wil be:
1.- Create vg00 with the following command sintax: make_tape_recovery -x inc_entire=vg00 -I -v -a /dev/rmt/0mb
2.- Power off the server
3.- Extract from bays current 18Gb's disks
4.- Place in same bays new 36Gb's disks.
5.- Start server and boot from ignite tape.
6.- recover system under new disks.

After these steps my server will be ready to work with the new disks devices?
If any harware change occurs whole external storage devices will be available to work after done this change?

Rgds.

[Johnson Punniyalingam]

Hi

>> my server will be ready to work with the new disks devices?

Yes, with new 36Gb's disks

If any harware change occurs whole external storage devices will be available to work after done this change? <<

Yes, They should be available , Precisely
we are using the Ignite_restore of the same Server,

better to do

# insf -e
# ioscan -fnC disk

Once you have recovered under the New 36GB's disk

Thanks,
Johnson

[OldSchool]

also, be aware that the ingite recovery will not, by itself restore the mirroring. By that, I mean that after ignite is done, the disks in vg00 will have to be mirrored by hand.

you might want to search the forums for "when_good_disks_go_bad" as the tutorials within it will walk you thru the steps.

[Jose Mosquera]

Ok, in fact no hardware changes will be exists because is the same server. In the poor of cases wich recomendations suggest me previous the change, i.e:
#vgcfgbackup -u /dev/vg00
#vgexport -p -v -m vg00.map /dev/vg00

Rgds.

[Jose Mosquera]

Thanks OldSchool,

I know that a Mirror/UX must be done under alternate boot disk. So a specific question about, boot capabilities of the Primary disk are restablished by the ignite's recover procedure?

Thkx.

[James R. Ferguson]

Hi (again):

> Ok, in fact no hardware changes will be exists because is the same server. In the poor of cases wich recomendations suggest me previous the change, i.e:
#vgcfgbackup -u /dev/vg00
#vgexport -p -v -m vg00.map /dev/vg00

This isn't necessary for vg00 since your Ignite will recreate (begining with a 'pvcreate') the physical disk that you select for your vg00. Its logical volumes and filesystems will be built and re-populated with data from your Ignite tape.

> I know that a Mirror/UX must be done under alternate boot disk. So a specific question about, boot capabilities of the Primary disk are restablished by the ignite's recover procedure?

Yes, this will be performed as a natural part of the Ignite setup of a new 'vg00'.

I would do a preview mode 'vgexport' of all of your non-vg00 volume groups and include the VGID in the mapfiles you generate.

# vgexport -m /tmp/vgNN.map -s -p -v vgNN

...and copy the mapfile to somewhere where you can reload it!

Adding the VGID to the mapfile will allow you to 'vgimport' using the volume group signitures on your disks. This is "insurance" in the event that your physical pv_paths change when the server hardware is re-scanned.

Ignite offers the option to import or not your non-vg00 disks. The above is extra insurance.

Regards!

...JRF...