any way at all to change the max pe per pv parameter without disruption?

[Geert Swillens]

Gentlepeople,

because of a storage migration, we need to add new pv's to some vg's and do a pvmove -n. It has come to my attention that the sysadmin who did the setup didn't specify the option of max pe per pv on vgcreate, so it is set to the max necessary with the disks at that time. With the ever expanding disk sizes, this is not the way to go, and now, we are in deep trouble. Is there anyway exept a backup-restore with vg recreate to change this parameter?

If there isn't, what's the fastest way to go from situation old vg on old pv's to new vg on new pv's?

cheers,

Geert

[vofsky · Accepted solution]

Hi Geert,
you have two choice.one is backup the whole system with make_tape_recovery,the other is vgmodify.
I have uploaded the vgmodify already.you can download it.
example: reset the MAX pe
vgmodify -e pe_number /dev/vgxx /dev/dsk/cxtxdx

[Robert-Jan Goossens]

Hoi Geert,

If you have a good support contract, call the HP CRC and ask for the vgmodify tool.

more info in this thread.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=619420&admit=-682735245+1145003982630+28353475

Regards,
Robert-Jan

[Geert Swillens]

thanks,

can you tell me how to unpack the .null file you uploaded? I don't seem to be able to make something of it.

What is the latest version of this VGModify tool? I found one on the forum dated around 2004, version 1.27. Is the one you uploaded a more current version?

one thing I already found in the readme is following line :

"for each pv, if the new disk based volume group reserved area (VGRA) will not fit before the user data, at the start of the disk, then vgmodify checks if the first PE is free for non-bootable PVs. If it is free, than vgmodify will steal this PE to allow VGRA to be expanded."

How can you check this before running the tool?

cheers,
Geert

[Steven E. Protter]

Shalom Geert,

The null file does not need to be unpacked, it needs to be renamed and made executable with the chomod command.

Normally, you can not change a volume group once it has been created.

Normally, what needs to be done is a vgexport of the volume group and vgcreate.

Its important to add the parameter -p to the volume group create.

That some number is set lower than the default which is 255 for max volumes. When the max volumes is set high, the available physical extents is spread over too many disks, leading to the problem you encountered in your volume group.

Since under normal circumstances its not possible to change a vg after creation, its important to set max physical volumes to a figure that is realistic but not likely to be exceeded in the lifetime of the volume group.

SEP

[Geert Swillens]

steven,

I believe the -p was added, since I'm on a max volumes = 60 value.

I think the -e option wasn't used, which sets the max_physical_extents. at the time, the host was provided with physical volumes of around 20 GB, which resulted in 1230 PE with a pe-size defined at 16 MB. since this is higher than the default 1016, that value was set.

so the max pv value is realistic, but the max pe per pv is not, since 20 GB was ok 3 years ago, but at this point, I want to provide the server with 50 GB volumes.

We are talking about a 1TB SAP database VG here, so that will put a major downtime on my server to perform backup restore.

I'm still willing to try this vgmodify tool on a testserver anyway. Anyone know if it works on 11.23, since the readme said works on 11.11?

thanks for feedback and clarification SEP,

cheers,
Geert