max PV and maxvgs reached, need to expand

[zhi wang_1]

My system's max_volume group has reached its limit. And the max_physical volume was set to default value, 16. Now I have to bump it up to 255. What is the best way to do it without destroying the data files already on the vg. Can it be done without a reboot? Your help will be greatly apprecited. Thanks a lot. Z

[Pedro Cirne]

Hi,

Unfortunately you can't change the max_pv on the VG without recreating it....you'll have to backup/restore or copy data to another VG.

Enjoy :-)

[Pete Randall]

Since you can't increase max_pv without re-creating the VG, you might try increasing the kernel parameter maxvgs. Then you can create a new larger vg and copy into it.


Pete

[DCE · Accepted solution]

The max_physical volume cannot be changed after a volume group has been created. You will have to create a new volume group with the larger number. Also make sure your phyical extent size is large enough to allow for additional (larger disks) to be added at a later date. The PE size is adequate for the largest disk in the vg at vg creation time, but if you add a much larger disk later, you will find that the PE is inadequate.

[zhi wang_1]

Thank you for all your helpful input. Suppose I increased the max_vgs value and is going to create /dev/vg10. Now what is the correct minor #? mknod /dev/vg10/group c 64 0x100000 or something else? what would it be if I want to create /dev/vg11 in the future?

Thanks a lot.

[saju_2]

Hi

The syntax you told is correct but make sure that the minor number you are specifying is not already used by another VG.

use ll /dev/vg*/group|awk '{print $6,$10}' to find out the minor number and vg's which already exists. Then put another minor number to the newly created group file.

It is always better to assign some points to the perople who have helped to resolve your problem rather than giving thanx and regards

CS

[Devender Khatana]

Hi,

The correct minor no should be unique in all group files. Do
#ls -ltr /dev/*/group

crw-r----- 1 root sys 64 0x000000 Oct 24 2004 /dev/vg00/group
crw-rw-r-- 1 root sys 64 0x010000 Nov 5 2004 /dev/vglock/group
.
.
.
And so on.
The 0x??0000 should be unique for all VG's
Follow the sequence to 00,01,02,03,04,05,06,07,08,09,10,11 and so on in place of ??.

HTH,
Devender

[zhi wang_1]

I was told that since the minor# is hexadecimal it should be 0x0a0000. Which is correct, 0x100000 or the former?

[Patrick Wallek]

The minor number IS in HEX. So if you have VG10, and want to keep the minor number consistent, use 0x0a0000.

[Devender Khatana]

Hi,

Both are correct only. Allthough if you follow the sequence as posted by Patrick, you should use 01,02,03,04,05,06,07,08,09,0a,0b,0c & so on.

The important thing is that it should be unique & can not be repeated in one system.

Regards,
Devender

[saju_2]

Hi

You can use any minor number in 0xNN0000 format where NN should be unique within your server. Below is a list of some minor numbers in my server.

0x000000
0x030000
0x060000
0x260000
0x230000
0x240000
0x250000
0x270000
0x220000
0x210000
0x200000
0x290000
0x2a0000
0x2b0000
0x280000
0x440000
0x430000
0x400000
0x420000
0x410000
0x470000
0x460000
0x450000
0x4a0000
0x490000

Regards
CS

[Jim Mallett]

You would want to go with the hex version, so for your 10th VG use: 0A
11th: 0B
etc...

Be careful when changing your max_vgs. Say you set it to 10, but one of them was numbered 0x0b0000, it would not mount. The max_vgs should be set no lower than your highest minor number. (dont ask me why I know that one).

Jim