Find it

Thursday, September 24, 2009

AIX extendvg issue

AIX extendvg issue -

While performing some task related to expanding the VG I got below error -

0516-1163 extendvg: datavg2 already has maximum physical volumes. With the maximum
number of physical partitions per physical volume being 2032, the maximum
number of physical volumes for volume group datavg2 is 16.
0516-792 extendvg: Unable to extend volume group.



When I tried adding LUN/disk to VG system thrown above error on my beautiful face... :)

When I checked what is the reason that I received such a error then I realized that I have reached to maximum number of PV limit and now my next job is to increase the number of PVs for problematic VG.

# lsvg datavg2
VOLUME GROUP: datavg2 VG IDENTIFIER: 002703ff00004c0000000109f5693a39
VG STATE: active PP SIZE: 16 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 24598 (393568 megabytes)
MAX LVs: 512 FREE PPs: 9020 (144320 megabytes)
LVs: 78 USED PPs: 15578 (249248 megabytes)
OPEN LVs: 78 QUORUM: 16 (Enabled)
TOTAL PVs: 16 VG DESCRIPTORS: 16
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 16 AUTO ON: yes
MAX PPs per VG: 128016
MAX PPs per PV: 3048 MAX PVs: 16
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable


I tried with command -

# chvg -B datavg2

However I got error while converting this VG to BIG VG -


Anyways now question is how to get rid of this? We have to convert this normal Vg to BIG VG.

IMP: When you want to convert normal VG to big VG the mandatory condition is - There must be enough free partitions available on each physical volume for the VGDA expansion for this operation to be successful, at least 2 PP as per my observation.
There must be enough free partitions available on each physical volume for the VGDA expansion for this operation to be successful. Because the VGDA resides on the edge of the disk and it requires contiguous space for expansion, the free partitions are required on the edge of the disk. If those partitions are allocated for user usage, they will be migrated to other free partitions on the same disk. The rest of the physical partitions will be renumbered to reflect the loss of the partitions for VGDA usage. This will change the mappings of the logical to physical partitions in all the PVs of this VG. If you have saved the mappings of the LVs for a potential recovery operation, you should generate the maps again after the completion of the conversion operation. Also, if the backup of the VG is taken with the map option and you plan to restore using those maps, the restore operation may fail since the partition number may no longer exist (due to reduction). It is recommended that backup is taken before the conversion, and right after the conversion if the map option is utilized. Because the VGDA space has been increased substantially, every VGDA update operation (creating a logical volume, changing a logical volume, adding a physical volume, and so on) may take considerably longer to run.



When I checked for all PVs assocoated with VG datavg2 and looked for their Used PPs and Free PPs status, I guess I am getting above error because I have following problem - see few of my disk does not have free PPs at all - like below you can see hdisk7, hdisk50, hdisk50 and so on...

# lsvg -p datavg2
datavg2:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk43 active 475 136 64..72..00..00..00
hdisk71 active 475 131 00..03..90..38..00
hdisk22 active 2047 236 00..236..00..00..00

[.....]

hdisk25 active 2047 856 00..409..137..00..310
hdisk7 active 952 0 00..00..00..00..00
hdisk50 active 475 0 00..00..00..00..00


[.....]

hdisk62 active 475 0 00..00..00..00..00
hdisk38 active 2047 824 00..24..00..390..410
hdisk36 active 2047 603 00..409..194..00..00

[.....]

Then I checked PP and LV allocations for hdisk7

# lspv -M hdisk7 | more
hdisk7:1 udbdevl4:1152
hdisk7:2 udbdevl4:1153
hdisk7:3 udbdevl4:1154
hdisk7:4 udbdevl4:1155
hdisk7:5 udbdevl4:1156

[.....]

hdisk7:949 lv52:1801
hdisk7:950 lv52:1802
hdisk7:951 lv52:1803
hdisk7:952 lv52:1804

OK.. So hdisk7 is totally full and it seems we have good enough space or Free PPs on hdisk38, so how about migrate the logical partitions from hdisk7, hdisk50, hdisk62 and so on to hdisk38 which has enough space. It seems to be a good idea.

So let’s go for it.

Now first I going to see on hdisk38 how the PPs are laid out -

# lspv -M hdisk38

[.......]
hdisk38:1244 JDQD.db:208
hdisk38:1245 JDQD.db:209
hdisk38:1246 JDQD.db:210
hdisk38:1247 JDQD.db:211
hdisk38:1248-2047

Ok.. from 1240 to 2047 we have a free PPs. Now let us migrate on LP from hdisk7 to hdisk38 on next available PP that is 1248

# migratelp lv52/1804 hdisk38/1248
migratelp: Mirror copy 1 of logical partition 1804 of logical volume
lv52 migrated to physical partition 1248 of hdisk38.

# migratelp lv52/1803 hdisk38/1249
migratelp: Mirror copy 1 of logical partition 1803 of logical volume
lv52 migrated to physical partition 1249 of hdisk38.

So here I made at least two PPs available for hdisk7 and like the same way we are going to do it same for hdisk50, hdisk62 and hdisk66 which are full, see below O/P -

# lsvg -p datavg2
datavg2:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk43 active 475 136 64..72..00..00..00
hdisk71 active 475 131 00..03..90..38..00
hdisk22 active 2047 236 00..236..00..00..00

[.....]

hdisk25 active 2047 856 00..409..137..00..310
hdisk7 active 952 2 00..00..00..00..02
hdisk50 active 475 2 00..00..00..00..02


[.....]

hdisk50 active 475 2 00..00..00..00..02
hdisk38 active 2047 816 00..24..00..382..410
hdisk36 active 2047 603 00..409..194..00..00

[.....]


You can also see hdisk38 status or changes -

# lspv -M hdisk38

[.....]
hdisk38:1248 lv52:1804
hdisk38:1249 lv52:1803
hdisk38:1250 lv52:696
hdisk38:1251 lv52:695
hdisk38:1252 lv52:995
hdisk38:1253 lv52:994
hdisk38:1254 udbdevl4:1124
hdisk38:1255 udbdevl4:1123
hdisk38:1256-2047

Now we are going to try converting VG to BIG VG orI can say best as increase number of PPs to a VG

# smitty chvg


[Entry Fields]
* VOLUME GROUP name [datavg2] +

[Entry Fields]
* VOLUME GROUP name datavg2
* Activate volume group AUTOMATICALLY yes +
at system restart?
* A QUORUM of disks required to keep the volume yes +
group on-line ?
Convert this VG to Concurrent Capable? no +
Change to big VG format? yes +
Change to scalable VG format? no +
LTG Size in kbytes 128 +
Set hotspare characteristics n +
Set synchronization characteristics of stale n +
partitions
Max PPs per VG in units of 1024 32 +
Max Logical Volumes 256 +


OK.. See now VG has became a BIG VG -

# lsvg datavg2
VOLUME GROUP: datavg2 VG IDENTIFIER: 002703ff00004c000000010d8f8b6358
VG STATE: active PP SIZE: 32 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 11103 (355296 megabytes)
MAX LVs: 512 FREE PPs: 4547 (145504 megabytes)
LVs: 23 USED PPs: 6556 (209792 megabytes)
OPEN LVs: 23 QUORUM: 9 (Enabled)
TOTAL PVs: 17 VG DESCRIPTORS: 17
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 17 AUTO ON: yes
MAX PPs per VG: 130048
MAX PPs per PV: 2032 MAX PVs: 64
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable

Cool stuff, good learning...

5 comments:

  1. Hi Nilesh, do you know how to extendvg to use those hard disk previously used by veritas volume manager. it prompted error msg:
    physical volume contain a veritas volume group.
    Though the DG has been destroyed using veritas vm.thanks.

    ReplyDelete
  2. Hi,

    Thanks for the question. In my opinion you can do this using below method -

    # dd if=/dev/zero of=/dev/rhdisk# bs=64k count=100

    # rmdev -dl hdisk#

    # cfgmgr

    After this procedure you should able to add those disks to existing VG. Try this if you have any test box with same issue. Revert in case it works for you.

    Thank you,
    Nilesh

    ReplyDelete
  3. Thanks for the article ;)

    If you have many VG in the system....This is an option:

    lsvg -p [VG]

    Copy al hdisk and use a parameter tail to take only the 2 last lines.

    lspv -M [hdisk]|tail -2

    ReplyDelete
  4. Thanks for the article. While extending the volume group the server showed an error. After researching I found that the Volume Group is a small VG and I had to convert the VG to BIG VG to add additional PVs. I followed the article at http://www.vmexplore.com/how-to-convert-small-vg-big-vg-scalable-vg/ to fix the issue.

    ReplyDelete