I have free partitions in my volume group but why I can’t extend a logical volume?

Answer:
Q1. What does the allocp error mean?
A1. The allocp error means that the system is unable to fulfill the allocation request for the logical volume extension and that doesn't mean necessarily that the volume group doesn't have enough space. There may be other certain LVM configurations/restrictions preventing the extension of a logical volume.

Q2. When does the extension of a logical volume fail?
A2. One of the reasons below might cause the problem:

1- If the logical volume has a Single Copy and there are no enough free partitions in the volume group that satisfy the request.

2- If the logical volume is Mirrored and one of the disks that accommodates the mirror copies has no enough partitions to satisfy the request, yet we have enough free partitions on the volume group. The reason for this failure is the strict allocation policy of the AIX-LVM. With mirroring where several copies of the same data are used, LVM activate the strict policy by default for the mirrored logical volumes to avoid the mirroring of the same LPs on the same exact disk. A failure of that disk would result in the complete loss of the mirrored logical volume. In most circumstances, this is not a safe configuration, therefore, by default AIX-LVM does not allow you to place more than one copy of a logical partition on a given physical volume.

3- If the Upper Bound attribute for the logical volume is set to a certain number of disks that have no free partitions, yet we have more disks within the volume group with free partitions.

Note: The upperbound attribute, sets the maximum number of physical volumes for new allocation.

4- Using a Striped Logical Volume: The logical partitions allocated for the striped logical volume must be equally located on every physical volume composing the striped logical volume, hence if the striped logical volume is scattered over three physical volumes for example and they are not equal in size then the logical volume can be only expanded by even multiple of the striping width that does not exceed the available space on the smallest disk. Yet we still have free partitions in the volume group.

5- If we are using Mirror Pools:

- Logical volumes that are enabled to use mirror pools will only allocate partitions on the physical volumes in that mirror pools, hence if we don't have free partitions on the mirror pool disks, we will not be able to extend the logical volume. Yet we may still have free space in the volume group.
- If there is mismatch between the LVM mirroring structure and the mirror pool structure, the extension of the logical volume/filesystem will fail.

Q3. How can I troubleshoot and resolve the failure of the logical volume/file system extension?

A3. We need to look at different LVM configurations:

1- If we are trying to extend a logical volume that have a single copy:
We need to make sure that we have enough free partitions that satisfy the extension request. By running the lsvg <VGname> and looking at the FREE PPs number we will know how may free partitions in the volume group:

# lsvg testVG | grep FREE
MAX LVs: 256 FREE PPs: 60 (1920 megabytes)

So any attempt to add more than 60 LPs to any logical volume within this volume group will fail with the allocp error.

2- If we are trying to extend a mirrored logical volume:
We need to check the free partitions on all the disks that accommodate the both copies:

# lsvg -l testVG
testVG:

LV NAME	TYPE	LPs	PPs	PVs	LV STATE	MOUNT POINT
loglv07	jfs2log	1	2	2	close/syncd	N/A
fslv03	jfs2	592	1184	2	closed/syncd	/testfs
fslv17	jfs2	32	32	1	closed/syncd	/testfs1

# lslv -l fslv03
fslv03:/testfs

PV	COPIES	IN BAND	DISTRIBUTION
hdisk2	592:000:000	21%	128:127:127:128:082
hdisk1	592:000:000	16%	128:095:127:128:114

# lsvg -p testVG
testVG:

PV_NAME	PV STATE	TOTAL PPs	FREE PPs	FREE DISTRIBUTION
hdisk1	active	639	14	00..00..00..00..14
hdisk2	active	639	46	00..00..00..00..46

# lsvg testVG | grep FREE
MAX LVs: 256 FREE PPs: 60 (1920 megabytes)

# chfs -a size=+500M /testfs
0516-404 allocp: This system cannot fulfill the allocation request.
There are not enough free partitions or not enough physical volumes
to keep strictness and satisfy allocation requests. The command
should be retried with different allocation characteristics.

Conclusion: fslv03 logical volume is mirrored between hdisk1 and hdisk2, we can’t use all the free partitions on the volume group because the strict allocation policy of AIX LVM. We only can expand the file system/logical volume by number of partitions that allow each logical partition copy to be on separate physical volume.

Solution: add more disk(s) to the volume group.

3- We need to check the upper bound attribute for the logical volume to see if it is less than the number of the disks within the volume group:

# lsvg -p testvg

testvg:

PV_NAME	PV STATE	TOTAL PPs	FREE PPs	FREE DISTRIBUTION
hdisk18	active	639	634	128..123..127..128..128
hdisk19	active	639	634	128..127..127..128..128
hdisk20	active	639	634	128..128..127..128..128
hdisk21	active	639	634	128..128..127..128..128

# lslv fslv02 | grep -i upper
INTRA-POLICY: middle UPPER BOUND: 1

# lslv -l fslv02
fslv02:/sizefs

PV	COPIES	IN BAND	DISTRIBUTION
hdisk18	005:000:000	100%	000:005:000:000:000

# extendlv fslv02 640
0516-404 allocp: This system cannot fulfill the allocation request.
There are not enough free partitions or not enough physical volumes
to keep strictness and satisfy allocation requests. The command
should be retried with different allocation characteristics.

Conclusion:
The upper bound attribute for the logical volume is preventing the logical volume extension.

Solution:
Increase the upper bound for the logical volume:
# chlv –u 4 fslv02
# extendlv fslv02 640
#

4- If the logical volume is a striped logical volume:
We need to check the available partitions in all the disks this logical volume is scattered over:
# lsvg -p testvg
testvg:

PV_NAME	PV STATE	TOTAL PPs	FREE PPs	FREE DISTRIBUTION
hdisk3	active	319	209	64..00..17..64..64
hdisk5	active	159	49	00..00..00..17..32
hdisk6	active	639	529	128..18..127..128..128

# lslv stripedlv | grep SCHED
COPIES: 1 SCHED POLICY: striped

# lslv -l stripedlv
stripedlv:/stripedfs

PV	COPIES	IN BAND	DISTRIBUTION
hdisk6	110:000:000	100%	000:110:000:000:000
hdisk3	110:000:000	58%	000:064:046:000:000
hdisk5	110:000:000	29%	032:032:031:015:000

# extendlv stripedlv 150
0516-1034 lquerypv: Not enough physical partitions in physical volume hdisk5.
0516-788 extendlv: Unable to extend logical volume.

Conclusion:
Because the logical partitions allocation for the striped logical volumes must be equally located on every physical volume composing the striped logical volume, then we can’t extend the logical volume by even multiple of the striping width that exceed the available space on the smallest disk.

Solution:
There is no solution for such an issue and we should take a backup for this logical volume and then restore it in disks that have equal size. To avoid this issue to happen again, initially we should create the striped logical volumes in disks that have equal sizes.

5- If the logical volume is enabled for mirror pools:

a. We need to check the free partitions on the mirror pool disks:

# lsvg -l testvg
testvg:

LV NAME	TYPE	LPs	PPs	PVs	LV STATE	MOUNT POINT
fslv02	jfs2	5	10	2	close/syncd	/sizefs
loglv02	jfs2log	1	1	1	closed/syncd	/N/A

# lslv fslv02 | grep -i POOL
COPY 1 MIRROR POOL: PoolA
COPY 2 MIRROR POOL: PoolB
COPY 3 MIRROR POOL: None

# lsvg -P testvg

Physical Volume	Mirror Pool
hdisk18	PoolA
hdisk19	PoolB
hdisk20	None
hdisk21	None

# lsvg -p testvg
testvg:

PV_NAME	PV STATE	TOTAL PPs	FREE PPs	FREE DISTRIBUTION
hdisk18	active	636	631	125..125..127..127..127
hdisk19	active	636	630	127..122..127..127..127
hdisk20	active	636	636	128..127..127..127..127
hdisk21	active	636	636	128..127..127..127..127

# lsvg -m testvg

Logical Volume	Copy 1	Copy 2	Copy 3
fslv02	PoolA	PoolB	None
loglv02	None	None	None

# extendlv fslv02 640
0516-404 allocp: This system cannot fulfill the allocation request.
There are not enough free partitions or not enough physical volumes
to keep strictness and satisfy allocation requests. The command
should be retried with different allocation characteristics.

Conclusion: Because the logical volume is enabled to use the mirror pools so it will only allocate partitions on the physical volumes assigned to this mirror pools.

Solution: Add more disks to the mirror pools:
# chpv -p PoolA hdisk20
# chpv -p PoolB hdisk21
# extendlv fslv02 640
#

b. If we have free partitions on the mirror pool disks and the new allocation request still failing then we need to make sure that the mirror pool structure is in sync with the LVM mirroring structure. Mirror pools have a separate structure from LVM mirroring. Information for mirror pool is stored in 3 places: PV, LV and VG. In some cases, you can remove a copy of a logical volume with rmlvcopy (not in LVM anymore), but mirror pool commands will still show it as an existent copy. That will cause LVM commands to fail. So we need to make sure LVM commands (mirrorvg, mklvcopy...) and Mirror Pool commands (chpv -p, chlv -m copy1=.., chvg -M....) are in sync all the time.

Example:
1- Created a new scalable volume group with two disks and created two mirror pools:
# mkvg -S –y testvg hdisk1 hdisk2
# chpv -p pool1 hdisk1
# chpv -p pool2 hdisk2

2- Created logical volume and enabled mirror pools to the copies of the logical volume:
# mklv -t jfs2 –y testlv testvg 10
# chlv -m copy1=pool1 testlv
# chlv -m copy2=pool2 testlv

3- Created mirror copies of the logical volume and synchronized them:
# mklvcopy testlv 2
# syncvg –v testvg

4- Lets say I need to replace hdisk1 with new disk "hdisk3":

4.1. I added a new disk to the volume group, created a new mirror pool and enabled the logical volume for using the new mirror pool and added a mirror copy for the logical volume a well:

# extendvg -p pool3 testvg hdisk3
# chlv -m copy3=pool3 testlv
# mklvcopy testlv 3 hdisk3
# syncvg -v testvg

At this point the LVM structure is in sync with the mirror pool structure as we can see below:
# lsvg -m testvg

Logical Volume	Copy 1	Copy 2	Copy 3
testlv	pool1	pool2	pool3

# lsvg -l testvg
testvg:

LV NAME	TYPE	LPs	PPs	PVs	LV STATE	MOUNT POINT
testlv	jfs2	10	30	3	closed/syncd	N/A

4.2. Removed a copy for the logical volume with rmlvcopy and reduced hdisk1 form the volume group:

# rmlvcopy testlv 2 hdisk1
# reducevg testvg hdisk1

At this point a mirror copy is removed from the LVM structure but not from the mirror pool structure, because this is not the recommended way to replace disks from a mirror pool, we can see that mismatch between the mirror pool structure and the LVM structure using the commands below:

# lsvg -m testvg

Logical Volume	Copy 1	Copy 2	Copy 3
testlv		pool2	pool3

Note: If there is no mirror pool assigned to copy 1, it should say None.

# readvgda hdisk2 | grep -p "LV 1"
------- LV 1 ------
lvname: testlv
lv_state: 1
flags: 0x21
mirror_policy: 2
num_lps: 10
maxsize: 512
stripe_exp: 0
striping_width: 0
lv_avoid: 0
child_min_num: 0
upperbound: 1024
lv_opt: 0x6
strict: y
relocatable: y
interpolicy: m
intrapolicy: m
mirror_pool[]: 1 2 3 <==
------ lvcb ------
type: jfs2
created_time: Mon Apr 4 06:28:55 2016
modified_time: Mon Apr 4 08:17:42 2016
mod_machine_id: 7A9674C00
label: None
fs:
dev_uid: 0
dev_gid: 0
dev_perm: 432
------------------

# lsvg -p testvg
testvg:

PV_NAME	PV STATE	TOTAL PPs	FREE PPs	FREE DISTRIBUTION
hdisk2	active	1275	1265	255..205..255..255..255
hdisk3	active	1275	1265	255..205..255..255..255

# extendlv testlv 1
0516-404 allocp: This system cannot fulfill the allocation request.
There are not enough free partitions or not enough physical volumes
to keep strictness and satisfy allocation requests. The command
should be retried with different allocation characteristics.

Conclusion:
The new allocation request is trying to use partitions from mirror pool that no longer exists "pool1-hdisk1", because there is a mismatch between the LVM mirroring structure and the mirror pool structure.

Solution:
1. Remove mirror pools totally from the system for this VG: from LV and PV level:
# chlv -M 1 testlv
# chlv -M 2 testlv
# chlv -M 3 testlv
# chpv -P hdisk2
# chpv -P hdisk3

2. Assign the disks to new mirror pools.
# chpv -p pool1 hdisk2
# chpv -p pool2 hdisk3

3. Enable the mirror pools to the logical volumes.
# chlv -m copy1=pool1 testlv
# chlv -m copy2=pool2 testlv

4. Now we can extend the logical volume without a problem:
# extendlv testlv 2
#

The commands below are to confirm that the LVM and the mirror pool structure are in sync:

# lsvg -m testvg

Logical Volume	Copy 1	Copy 2	Copy 3
testlv	pool1	pool2	None

# readvgda hdisk2 | grep -p "LV 1"
------- LV 1 ------
lvname: testlv
lv_state: 1
flags: 0x21
mirror_policy: 2
num_lps: 12
maxsize: 512
stripe_exp: 0
striping_width: 0
lv_avoid: 0
child_min_num: 0
upperbound: 1024
lv_opt: 0x6
strict: y
relocatable: y
interpolicy: m
intrapolicy: m
mirror_pool[]: 1 2 0 <==
------ lvcb ------
type: jfs2
created_time: Mon Apr 4 09:02:00 2016
modified_time: Mon Apr 4 09:10:19 2016
mod_machine_id: 7A9674C00
label: None
fs:
dev_uid: 0
dev_gid: 0
dev_perm: 432
------------------

Suggestion:
If we need to remove all the disks from a mirror pool and assign new disks to it:
1. Remove mirror pools totally from the system for this VG: from LV and PV level.
2. Remove unnecessary mirror at LVM level (unmirrorvg from the disks that need to be replaced).
3. Remove the disks from the volume group and assign new disks.
4. Create LVM mirror to the new disks.
5. Create new mirror pools and enable the logical volume copies to use mirror pools.

IBM's support team is committed to assisting you in obtaining the highest value from our products and services.

Regards,
Mohamed Othman