Not enough free physical extents

[itrc55]

Hi,

But still I don't understand how to use vgmodify on 11.31.

Thanks

[Matti_Kurkela]

> trying to use the vgmodify command with any option i see this message

>sdh014 #vgmodify -v -r appsvg
>Usage:

In other words, vgmodify is trying to tell you that you used a wrong combination of options.

The "Usage:" list is grouped according to various use cases. Each use case has some mandatory options, and some optional options. The optional options are within [brackets].

The very first use case is:
>For deactivated version 1.0 volume groups,
>vgmodify
>[-v]
>[-n]
>[-r]
>[-e MaxPhysicalExtents]
>[-p MaxPhysicalVolumes]
>[-l MaxLogicalVolumes]
>VolumeGroupName
>[...]

This matches the command line you entered. From your question in the original post, it is obvious that the "appsvg" volume group exists.

Note that the use case is for _deactivated_ volume groups of _version 1.0_.

First, since you did not say anything about running "vgchange -a n appsvg" your "appsvg" VG is probably still active, i.e. it is _not_ deactivated.

Second, the "vgdisplay appsvg" output in your original post indicates:

>VG Version 2.2

... so this is _not_ a version 1.0 volume group.

That's two reasons why your command did not work!

For a version 2.2 volume groups, the only applicable use cases are here:

>For activated volume groups version 2.0 and higher,
>vgmodify -a -E
>[-r]
>VolumeGroupName [pv_path ...]

>vgmodify -a -C DLC_Size
>[-r]
>VolumeGroupName pv_path

>vgmodify -a
>[-E]
>-S Max_VG_Size [-r] VolumeGroupName

In other words, to manipulate version 2.0 or higher volume groups at all, the VG must be activated.

Also, there is no -v option for version 2.0 or higher volume groups. (A third version why your command did not work!)

Looking at all the use cases together, the '-a' option is mandatory every time you use vgmodify to manipulate an activated VG.

According to the technical paper linked by Duncan, the options -E and -C are associated with changing the size of already-presented storage LUNs.

So, if your storage administrator expands an existing appsvg LUN instead of giving you an extra LUN for extending your appsvg volume group, you'll need "vgmodify -a -E appsvg" to make LVM see the added space.

Alternatively, if you need to shrink an existing LUN, you must first arrange for enough free space on the PV you wish to shrink (by reducing filesystems or using pvmove to move allocated extents elsewhere), then you can use "vgmodify -a -C appsvg /dev/disk/diskXX" to tell the LVM that the LUN that contains the diskXX PV is about to shrink, and only _after that_ you can tell your storage admin to shrink the LUN.

If the VG maximum size limit (for appsvg, the vgdisplay command in the original post says "VG Max Size 10t") turns out to be too small, then you can use "vgmodify -a -S appsvg" to change it. Your current VG size is 7194 extents * 64 MB/extent = about 460 GB. That is a lot less than the current max size of 10 Terabytes, so you can expand this VG a lot without hitting the maximum size limit.

If you add the "-r" option to any of the above-mentioned command lines, then vgmodify won't actually do the operation: it will only display what the results would be.

The version of vgmodify on your system seems to be more capable than the one on my 11.31 test system: your 11.31 system is apparently newer (or more up-to-date with patches) than my test system currently is.

You should use "man vgmodify": this command will display documentation that has been proofread by HP and should be in sync with the version of vgmodify you actually have.

MK