Let me first explain a bit of how historically the LVM evolved to what it is now. It will put things better in perspective so that when i answer your question the picture will be better understandable.

The LVM was introduced with AIX 3, a very long time ago (beginning of the nineties). Back then disks were measured in MB and hence the limitations of the LVM weren't really limitations at all:

- a PV (physical volume) can hold only 1019 PPs (phyiscal partitions)
- a VG (volume group) can contain only 32 PVs

When a VG is created the property of PP size is selected and it cannot be changed later. The only way is to backup the VG, delete and recrete it with a different PP size, recreate the LVs/FSs and then restore the backup. Since disks grew bigger and bigger and the PP size cannot be changed later PVs added later to VGs soon hit the 1019 PPs limit and that could only be rectified by a (time-consuming) backup-and-restore.

The "solution" (actually less solution than rather "workaround") IBM came up with was to introduce the "factor". By rearranging the meaning of a few bits in the respective counters (obviously) they allowed for PVs to hold multiples of these 1019 PPs by - at the same time - reducing the maximum number of PVs in a VG. e.g. a factor of 2 means a single PV (disk) can hold up to 2x1019=2038 PPs but the VG would be limited to hold 16 PVs instead of 32. Analogous for different factors. Notice that will do nothing to increase the maximum amount of space a VG can hold because the increased size of one disk will be offset by the reduction in the number of possible disks.

So, finally IBM came up with the "Big VG" and the "Scalable VG". The scalable VG did away with a lot of limitations the older "classic" VG had. The downside is that VG operations take ever so slightly (seconds at best) longer because the layout is a bit more complex. Also it is not possible to directly convert a classical VG into a scalable one and the management of a scalable VG takes a bit more space.

Short answer: you can't so backup, recreate and restore. You should do that anyway as i will explain further on:

Your PP size is ridiculously small (128MB) for a VG of this size (~5.2TB). The PP size should be the smallest amount by which you will ever want to increase/decrease a FS. Ask yourself if you need to increase a FS by 128MB and the most probable answer will be "certainly not". Increase the size to something sensible, perhaps 1GB.

Second, you have 29 disks in this VG. Most probably many of these disks are very small compared to the size of the VG. I suppose most of these disks are LUNs anyway therefore it makes sense to recreate at most 3-4 of these disks with the same total size and put the VG on it there. Future increases in size can be done by increasing the size of these LUNs and re-read the LUNs size (see the chvg -g command) instead of adding new LUNs to the VG.

For this to work you want to do away with the 1019-PP-per-disk maximum and hence it makes sense to recreate the new VG as a scalable VG where a PV can have a (practically) unlimited number of PPs. The slight penalty when managing scalable VGs in comparison to classical VGs is negligible.

I hope this helps.

bakunin