2 36GB Disk but only half size will be used in vg00

[Carsten Moser]

Hi

We using a HP9000 System with LVM /onlineJFS. Now
we have 2 new 36 GB Harddisks and added them to vg00. We did this using SAM. The Disks are fine (says STM) but only the half disk size (ca 17GB) is used. The VG has the full size extended (72 GB) but only 36 GB was added by SAM. Where's the rest ??????????????

[Pete Randall]

It's the PE size that was used when vg00 was originally created. If you look at the PE size and the max PE's value, you'll see that if can only accomodate 17GB. The only way to fix this is to use Ignite to backup and then re-create your VG00.


Pete

[Geoff Wild]

Yes - as Pete says - you used the wrong PE size.

vgdisplay vg00 |grep "PE size"

need to be 8 to use 36GB...

Now, I have a unsupported utility called vgmodify:

vgmodify(1M)



NOTE - vgmodify is currently unsupported. This version works on 11.11 only. Download vgmodify from here. The current version 1.27. As from 1.25 to the current version vgmodify no longer allows moving of the VGRA to the end of the disk (VGRA relocation) or stealing PEs from the end of the disk. However stealing PEs from the start of the disk has been reinstated. It is planned to allow VGRA relocation and stealing PEs from the end of the disk with a future version of vgmodify, once extra testing has taken place. The first versions made available more widely will not permit VGRA relocation.



NAME

vgmodify - modify an LVM volume group's attributes.

SYNOPSIS

/usr/sbin/vgmodify [-e MaxPhysicalExtents | -d DiskSize] [-p MaxPhysicalVolumes] [-l MaxLogicalVolumes] [-r] VolumeGroupName [pv_path] [pv_path] [.....]

Remarks

vgmodify cannot make changes if the volume group is activated.

DESCRIPTION

The vgmodify command alters the specified attributes on an existing VolumeGroupName volume group. Prior to the release of vgmodify these attributes could only be defined when the volume group was built i.e. when vgcreate(1M) was run.

Data held in any allocated physical extents (PE) will be unaffected by vgmodify. vgmodify does not relocate or otherwise alter user data.

-e, -p and -l arguments have the same meaning as these options have with vgcreate(1M). The MaxPhysicalExtents maximum number of physical extents per physical volume can be specified using the -d DiskSize argument rather than the -e. If any or all of the -e, -p or -l arguments is not used then the current values are used.

For each physical volume, if the new disk based volume group reserved area (VGRA) will not fit before the user data, at the start of the disk, then vgmodify checks if the first PE is free for non-bootable PVs. If it is free then vgmodify will steal this PE to allow the VGRA to be expanded. If space on any of the physical volumes is inadequate then vgmodify will exit without making any changes. Otherwise the new structures will be written to all the disks. If the new VGRA is smaller, such that an extra PE can be allocated at the start of the disk then vgmodify will make this change (e.g. where a previous vgmodify invocation stole the first PE). If the size of the disk differs from the size recorded in the structure data then, where possible, the structure data is corrected (this condition may occur where a vgcfgrestore(1M) is performed to a disk of a different size or a disk array LUN has been re-sized).

The physical volume type is defined when it is created with pvcreate(1M). Type is either bootable or not bootable. The type of all specified pv_path arguments will be switched. This is the only purpose for the pv_path list. This feature may be required when there is insufficient space to fit the enlarged VGRA on a bootable PV but the PV is not used for booting.

By far the biggest factors on the size of the VGRA are the MaxPhysicalVolumes and MaxPhysicalExtents. If you want to increase MaxPhysicalExtents but are unable to do so because of the size of the VGRA that is required then reduce MaxPhysicalVolumes. If you cannot reduce MaxPhysicalVolumes, because all the PVs are already in use, then consider splitting the volume group. This can be accomplished using a sequence of LVM commands:

This really only makes sense where the VG has one group of LVs using one set of PVs and the remaining LVs using a different set of PVs.
e.g. VG has LV1,2 and 3 on PVs 0 and 1. LV4, 5 and 6 on PVs 2,3,4 and 5.

vgchange -a n VG
vgexport -m MAP VG
vgchgid PV2 PV3 PV4 PV5
mkdir /dev/VG; mknod /dev/VG/group c 64 0xn0000
mkdir /dev/new_VG; mknod /dev/new_VG/group c 64 0xn0000
vgimport -m MAP /dev/VG PV0 PV1
vgimport -m MAP /dev/new_VG PV2 PV3 PV4 PV5
vgchange -s -a y -q n VG; vgchange -a y -q n -s new_VG
lvremove -f VG/LV4 VG/LV5 VG/LV6 new_VG/LV1 new_VG/LV2 new_VG/LV3
vgreduce -f VG; vgreduce -f new_VG
vgcfgbackup VG; vgcfgbackup new_VG

On completion, VG should contain three LVs (1,2 & 3) with PVs 0 & 1. And, new_VG should contain three LVs (4,5 & 6) across PVs 2,3,4 & 5.
Options and Arguments

vgmodify recognizes the following options and arguments:

pv_path The block device path name of a physical volume for which type change will be performed.

vg_name The path name of the volume group.

-e MaxPhysicalExtents Set the maximum number of physical extents that can be allocated from any of the physical volumes in the volume group. The default value for MaxPhysicalExtents is the current setting. The maximum number of physical extents can be a value in the range 1 to 65535.

-l MaxLogicalVolumes Set the maximum number of logical volumes that the volume group is allowed to contain. The default value for MaxLogicalVolumes is the current setting. The maximum number of logical volumes can be a value in the range 1 to 255. In most cases it is recommended to set this to 255 as it consumes very little space in the disk based structure data.

-p MaxPhysicalVolumes Set the maximum number of physical volumes that the volume group is allowed to contain. The default value for MaxPhysicalVolumes is the current setting. The maximum number of physical volumes can be a value in the range 1 to 255.

-d DiskSize Set the maximum number of physical extents that can be allocated from any of the physical volumes in the volume group based upon a disk of DiskSize. DiskSize is in units of kilobytes (Kbs) but a trailing m or g can be supplied for megabytes or gigabytes respectively. e.g. -d 400000, -d 500m or -d 12g.

-r Only report on the impact of the arguments specified do not make any changes. The volume group can be active when this argument is used.



EXTERNAL INFLUENCES

Environment Variables

LANG determines the language in which messages are displayed. If LANG is not specified or is null, it defaults to "C" (see lang(5)). If any internationalization variable contains an invalid setting, all internationalization variables default to "C" (see environ(5)).

EXAMPLES

Modify a volume group so that up to twenty physical volumes can be attached
vgmodify -p 20 /dev/vg03

Size structures such that 15 disks of 20Gb can be held in the volume group
vgmodify -p 15 -d 20g /dev/vg03

Change the type of all the pv_path disks and allow up to 5000 physical extents per physical volume
vgmodify -e 5000 /dev/vg03 /dev/dsk/c5t0d4 /dev/dsk/c7t0d2 /dev/dsk/c3t0d6

Report, do not change, on the impact of changing the volume group to have a maximum of 50 physical volumes, 1000 physical extents for each physical volume and change the type of one pv_path
vgmodify -r -p 50 -e 1000 /dev/vg03 /dev/dsk/c7t0d3



WARNINGS

A current backup of the volume group with vgcfgbackup(1M) should to be taken before running vgmodify.

After running vgmodify a new backup with vgcfgbackup(1M) should be taken.

If vgmodify steals physical extents for the VGRA then these extents will be unavailable for user data.

Toggling the physical volume type by specifying a pv_path list should be used with caution. Especially if altering the boot/root volume group.

The boot/root volume group can only be modified by booting in maintenance mode - see hpux(1M).

All physical volumes must be present for vgmodify to change the configuration.

Bootable physical volumes stipulate that the first extent on the disk start at a fixed block. If a non-bootable disk is specified in the pv_list and the first extent does not start at this block then vgmodify will exit unless all extents on the physical volume are free.


A shared volume group must be de-activated on all systems. Checks are only performed on the local system

Only works with 11i.

If you want it., let me know and I will upload...

Rgds...Geoff