Advice re: remaking VG without harming data

[Steve Edmunds]

Hi folks,

I have a new 2 node cluster sharing disks (not under MCSG control just yet) and I made the volumes without specifying "-p N" so got the default 16, which won't be enough in the long term...the disks are shared from an XP512.

My question is, what is the easiest way to remake the VG's so I can specify max 50 pv's step by step without losing data? And what is the "supported" way?

Thanks for any help!

Steve

[Bill Hassell]

There is no method to change this value once the volume group has been created. All the physical volume slots were allocated with no room to add any more. The data must be copied to a backup, the volume group destroyed and rebuilt with the appropriate options (including an extent size large enough to handle the largest size--4 megs is pretty small for hundreds of Gb). Both issues (max PV's and Extent size) must be large enough fior the future when the volume is created.

[Uday_S_Ankolekar]

There is no "supported" way to modify this information.
You need to backup the data, delete the VG and recreate VG.

-USA..

[John Poff]

Hi,

As mentioned, the only way to change the Max PVs value is to nuke and recreate the VG. One thing to keep in mind when you recreate the VG is that you might want to bump up the PE size also if you think you might be adding larger sized disks in the future. I've seen a couple of people get bitten when they have 9 Gb disks in a VG and they add 36 Gb disks to it, only to find that they can't use all 36 Gb because of the PE size.

JP

[Seth Parker]

Hey John,

Are you talking about the actual size of the PE or the max # of PEs (or both)? I've been in the situation you describe and thought that it was the max# that needed to be increased.

Sorry for the follow-on....

Regards,
Seth

[Rita C Workman]

OK...you got the deal on the vg.

You create a new vg with the options you 'really' wanted.

Now you have a couple choices you can make.

Obviously you would need a disk to just create the new vg...so do you have enough disk to account for the same space used by the old vg. If you do...you could just do an fbackup/frecover from your old disks vg to your new disks vg.

mount old vg /fs (source dir)
mount new vg /xfs (dummy mountpoint-destination dir)

cd /fs
fbackup -i . -f - | (cd /xfs; frecover -Xsrf - )

..and this will copy the data for you. It works for sparse files, largefiles (providing you set up your filesystem with largefile option) and has worked great for me ..Thanks Jim Ferguson.

Or as was mentioned you could backup to tape...blow out your old vg and recreate and then restore from tape. A much longer process now dependant on the quality of your backup and the tape.

Regards,
Rita

[James Murtagh]

Hi Steve,

You _can_ do this but it depends on whether all the VG header information will fit in the initial extent. As you will be removing the VG anyway it is worth trying during the procedure.

Steps:

1) Remove all the lvols
2) Remove the VG
3) Recreate the VG with new options
4) Recreate the lvols with exactly the same extent allocation policy as before, you will need all the lvdisplay -v outputs for this
5) fsck the filesystems to ensure they are ok
6) Mount the filesystems

For example:

# bdf|grep vg01
/dev/vg01/lvol1 40960 27762 12413 69% /kernlog
# vgdisplay -v vg01|egrep "Max PV|LV Name|LV Size"
Max PV 16
LV Name /dev/vg01/lvol1
LV Size (Mbytes) 40
# umount /kernlog
# lvremove /dev/vg01/lvol1
# vgremove vg01
# vgcreate -p 32 vg01 /dev/dsk/c1t4d0
# lvcreate -l 10 vg01
# fsck -F vxfs /dev/vg01/rlvol1
file system is clean - log replay is not required
# mount /dev/vg01/lvol1 /kernlog
# bdf|grep vg01
/dev/vg01/lvol1 40960 27762 12413 69% /kernlog

I haven't copied all the VG/LV standard ouput to keep the size down, but as you can see the filesystem is still intact on lvol1 as my VG headers could be included in the first extent even after increasing the max number of physical volumes.

Regards,

James.