vgversion(1M)vgversion(1M)NAMEvgversion - handles volume group version migration of an existing LVM
volume group
SYNOPSIS
vg_version_new vg_name
Remarks
The original version of LVM volume group is version 1.0 which is sup‐
ported on all HP-UX 11i releases. LVM volume group version 2.0 was
introduced on the March 2008 update of HP-UX 11i v3 and is available
for all updates on HP 11i v3 going forward. Versions 2.0 or higher
volume groups allow LVM to increase many of the limits constraining the
size of volume groups, logical volumes, and so on. When constrained
with the limits of the current configuration on version 1.0 volume
group, the command can be used to extend a few of the version 1.0 vol‐
ume group configuration limits.
For the HP-UX 11i v3 March 2009 Update and forward, a new command, is
provided to take advantage of the improvements in volume group version
2.0 or higher. The command allows in-place volume group migration from
1.0 to 2.0 or higher. The command also supports migration of a volume
group from any version 2.x to any other version 2.y.
DESCRIPTION
The command allows users to review and migrate the volume group version
vg_version_old of an existing volume group vg_name to the new volume
group version vg_version_new.
Options and Arguments
Review mode.
Review the effect of migrating the existing volume group to
volume group version vg_version_new but do not do the actual
migration.
When run in this mode, no updates to or happens, nor the vol‐
ume group configuration files of the existing volume group
present under are modified. This option can be used on an
active volume group.
Verbose mode. Be verbose in reporting.
Specify the volume group version to which the existing volume
group has to be migrated. The vg_version_new should be in
the format 2.x (where x starts from 0 and beyond).
vg_name The path name of a volume group to be migrated.
Supported Volume Group Migration
The command allows the migration between any two supported volume group
versions with the exception of moving back to version 1.0.
The following steps list the typical usage scenario of the command
while migrating a volume group vg_name to the volume group version
vg_version_new:
1) Use the option with the command, to review if vg_name can be
migrated to volume group version vg_version_new.
If required by the above step, prepare vg_name for actual migration
by :
· Modifying the LVM configuration characteristics of vg_name, if
it is found to be not supported by the volume group version
vg_version_new.
· Creating required space to accommodate vg_version_new's metadata
using either or increasing the LUN size.
2) Do the actual migration of the volume group vg_name:
· Appropriate recovery check points are created on the system by
the command, as part of the migration, to support recovery fol‐
lowing any interruption during the volume group migration
process or post successful migration.
· Following successful migration, vg_name is updated to the volume
group version vg_version_new.
3) Ensure that the volume group vg_name is migrated successfully to
the volume group version vg_version_new using vgdisplay(1M),
lvmadm(1M), and other LVM commands.
4) In either of the below cases, if required, run the restore script
with the volume group vg_name configuration file available on the
system to restore the volume group vg_name to the original volume
group version:
· The command was interrupted while migration was in progress
· Post successful migration to vg_version_new using the command.
The command succeeds when the below criteria are met:
· All physical volumes belonging to volume group vg_name have that
additional free space required to accommodate the volume group ver‐
sion vg_version_new metadata.
· All the current LVM configuration and characteristics of the exist‐
ing volume group vg_name and its logical volumes and physical vol‐
umes are supported by the volume group version vg_version_new.
The command is supported only on deactivated volume groups, but user
can review the migration when the vg_name is active. All physical vol‐
umes that belong to volume group vg_name must be available while per‐
forming the migration.
The volume group must be cluster unaware (use if vg_name were cluster
aware) before migration is made. The command fails if the volume group
vg_name has a cluster lock disk (see cmquerycl(1M)). The cluster lock
must be removed before initiating the volume group migration.
Before updating each of the physical volumes with the new metadata,
creates the following files under the directory in preparation of
migration to volume group version vg_version_new:
· A restore script, which can be used to restore the volume group
vg_name with the configuration of the volume group contained in the
configuration backup file specified to this restore script.
· A configuration backup file of the volume group vg_name which has
the configuration of original volume group version. User must use
this file while restoring the volume group to original volume group
version using the restore script.
· A configuration backup file, of the volume group vg_name which has
the configuration of volume group version vg_version_new. User must
use this file while restoring the volume group to volume group ver‐
sion vg_version_new using the restore script.
· A disks_file, which contains the list of physical volumes in the
volume group. The order of the physical volumes in this file is
decided by their order in or This file is generated to be used by
the restore script.
· A mapfile, which has the names of the logical volumes in the volume
group version 2.0 or higher. This file is generated to be used by
the restore script.
· A mapfile, which has the names of the logical volumes in the volume
group version 1.0 (applicable for migration of volume group version
1.0 to 2.0 or higher). This file is generated to be used by the
restore script.
Note: All the above files created during the command, continues to
exist on the system at the directory. These files may be useful during
restoration to new volume group version or in the case of recovery to
original volume group version. Use extreme caution before deleting
these files on the system or while using these files for restoration
purposes with the vgcfgrestore(1M) command.
User data present on any of the physical volumes belonging to the vol‐
ume group vg_name will be unaffected by the migration operation.
In volume groups version 1.0, LVM metadata is required to fit into a
single physical extent. In volume groups version 2.0 and higher, meta‐
data is not restricted to an extent. The LVM metadata for volume
groups version 2.0 and higher may consume more space than on volume
groups version 1.0. Please see the section in lvm(7) for more details.
Note: The major number changes from 64 to 128 when the volume group is
upgraded from 1.0 to 2.0 or higher volume group version.
If the command is interrupted before it completes, recovery steps might
be required. See the section below for details.
Using the Review Mode Option (-r) Prior to Migration
Users can use the review mode option of the command to check whether
the migration operation is possible. For example, the option can be
used to check whether all physical volumes have the additional space
required to accommodate the volume group version vg_version_new meta‐
data. Review mode can be used when the volume group is in activated
state. The review option of the provides the following details:
· Lists any feature or functionality contained in the existing volume
group vg_name which will not be supported in the migrating volume
group version vg_version_new resulting in the failure of migration.
For each such failure, the command displays the corresponding cor‐
rective action to be taken to prepare the volume group for success‐
ful migration.
· Whether all the physical volumes in the existing volume group
vg_name have sufficient space to hold the metadata for the migrating
volume group version vg_version_new.
For those physical volumes which do not have enough free space to
store the metadata of volume group version vg_version_new, review
mode displays the corrective actions to be taken to prepare the vol‐
ume group for successful migration (like freeing up required number
of extents at the end of the physical volume or increasing the size
of the physical volume by a specified size).
Migration of Volume Group Version 1.0 to Volume Group Version 2.x
Below are points to consider when migrating from volume group version
1.0 to version 2.x.
· If there are any entries in the bad block directory of any physical
volume in the volume group vg_name, fails the migration and reports
the physical volume holding entries in the bad block directory.
· The migration fails if the volume group vg_name has any physical
volumes which are configured as standby or active spare.
· Volume group versions 2.0 and higher do not support root, boot,
swap, or dump. If the volume group version of vg_name is 1.0 and is
configured with any of the above, the command fails the migration of
such volume groups to version 2.0 or higher.
· The migration of the volume group version includes moving the con‐
figuration details of the volume group present in the file to the
file, and converting all the device special files present under the
directory to the format of new volume group version vg_version_new.
This include changing the device file major and minor number.
· Except where noted above, the volume group version migration process
retains all other LVM configuration/characteristics of the existing
volume group vg_name and its logical volumes and physical volumes.
Following a successful volume group version migration, retains the
order of the physical volumes in the LVM configuration files.
Note: Volume group version 2.0 and higher do not support bad block
relocation. If any logical volume belonging to the volume group
vg_name has bad block relocation enabled, the command will change the
bad block relocation policy of the logical volume to 'NONE'.
Migration of Volume Group Version 2.x to Volume Group Version 2.y
Below is information regarding migration from volume group version 2.x
to a later version 2.y.
· The volume group version migration process retains all the LVM con‐
figuration and characteristics of the volume group vg_name and its
logical and physical volumes.
Following the successful volume group version migration, retains the
order of the physical volumes in the LVM configuration.
· The command will fail if the logical volume number of any logical
volume, minor number of volume group vg_name and pv key of any phys‐
ical volume in the volume group vg_name is beyond the supported lim‐
its even if the actual total number of logical volumes, physical
volumes and volume groups are still within the supported limits for
volume group version vg_version_new.
· Volume group migration from 2.x to 2.y (for example, 2.0 to 2.1 or
2.1 to 2.0) can be done provided the configuration limits defined
for the volume group vg_name is supported by volume group version
vg_version_new. For example, if the existing volume group has more
logical volumes than it is supported by the volume group version
vg_version_new, the migration will fail. Refer to the command out‐
put to see the details of the maximum supported limits for all the
supported volume group versions on LVM.
Creating Metadata Space When It Is Not Available on the Physical Volumes
If any physical volume(s) lacks the additional space required to hold
the volume group version vg_version_new metadata, the review mode
option of lists the minimum size required on each such physical vol‐
ume(s) for a successful migration.
To accommodate the space requirement for storing the metadata of the
vg_version_new, the user can do one of the following, prior to re-run‐
ning
· Free up the required space at the end of the physical vol‐
ume, as suggested by the command review mode output, by
relocating few user data extents with the help of the com‐
mand.
· Increase of the size of the LUN from storage device
(the newly added space is not under LVMs control
though) so as to minimally accommodate volume group
version vg_version_new metadata.
· Following successful command execution, if the
newly added space is not completely used by the
command, the user may use the command to add
extents to the physical volume that has been
expanded using the LUN expansion earlier. Alterna‐
tively, the user may choose to reduce this extra
space on the physical volume by performing LUN con‐
traction from the storage device.
Note: A combination of the above two options can also be
used to create space for metadata. Wherever possible, it
is preferable to add extra space (LUN expansion from the
storage device) rather than freeing up user extents.
There may be a combination of the two scenarios mentioned
above. There may be some free space (not under LVMs con‐
trol) available at the end of the physical volume, but
insufficient to place the entire metadata. In such
cases, the command will use the free extents from the
bottom of the physical volume to place the remaining
metadata.
Recovery
If is interrupted during its operation it may be neces‐
sary to re-apply the configuration to all the physical
volumes belonging to the volume group vg_name. To assist
with this process, the generates a restore script under
the directory. The user can run this restore script to
bring back the volume group vg_name to its initial state.
Alternatively, the user can run this restore script to
restore the configuration of volume group version vg_ver‐
sion_new, if the command successfully creates the corre‐
sponding configuration file.
To enable restoration of the volume group, saves the fol‐
lowing files in directory on the system. Refer to the
section for more information on these files.
To
re-
apply
the
con‐
fig‐
u‐
ra‐
tion
to
all
the
phys‐
i‐
cal
vol‐
umes
belong‐
ing
to
the
vol‐
ume
group
vg_name,
enter
the
fol‐
low‐
ing
com‐
mand:
To
apply
the
con‐
fig‐
u‐
ra‐
tion
of
vol‐
ume
group
vg_name
with
vol‐
ume
group
ver‐
sion
vg_ver‐
sion_new
to
all
the
phys‐
i‐
cal
vol‐
umes
belong‐
ing
to
it,
enter
the
fol‐
low‐
ing
com‐
mand:
EXTERNAL
INFLU‐
ENCES
Envi‐
ron‐
ment
Vari‐
ables
deter‐
mines
the
lan‐
guage
in
which
mes‐
sages
are
dis‐
played.
If
is
not
spec‐
i‐
fied
or
is
null,
it
defaults
to
"C"
(see
lang(5)).
If
any
inter‐
na‐
tion‐
al‐
iza‐
tion
vari‐
able
con‐
tains
an
invalid
set‐
ting,
all
inter‐
na‐
tion‐
al‐
iza‐
tion
vari‐
ables
default
to
"C"
(see
env‐
i‐
ron(5)).
RETURN
VALUE
returns
one
of
the
fol‐
low‐
ing
val‐
ues:
0 Suc‐
cess‐
ful
com‐
ple‐
tion.
>0 Error
con‐
di‐
tion
occurred.
EXAMPLES
Review
the
ver‐
sion
change
oper‐
a‐
tion
of
a
vol‐
ume
group
named
to
vol‐
ume
group
ver‐
sion
2.0:
Change
the
ver‐
sion
of
a
vol‐
ume
group
named
to
vol‐
ume
group
ver‐
sion
2.0:
Change
the
ver‐
sion
of
a
vol‐
ume
group
named
to
vol‐
ume
group
ver‐
sion
2.1:
Change
the
ver‐
sion
of
a
vol‐
ume
group
named
/dev/vg01
to
vol‐
ume
group
ver‐
sion
2.1
and
be
ver‐
bose:
WARNINGS
· If
the
com‐
mand
is
inter‐
rupted
prior
to
com‐
plet‐
ing
its
oper‐
a‐
tion,
then
restora‐
tion
to
all
phys‐
i‐
cal
vol‐
umes
in
the
vol‐
ume
group
may
be
required.
Use
the
restore
script
to
accom‐
plish
this
(see
the
sec‐
tion
for
more
infor‐
ma‐
tion).
· The
migra‐
tion
of
vol‐
ume
group
ver‐
sion
1.0
to
2.0
or
higher
requires
the
ker‐
nel
driver,
which
sup‐
ports
vol‐
ume
group
ver‐
sion
2.0
or
higher,
to
be
loaded.
· Dur‐
ing
migra‐
tion
of
vol‐
ume
group
ver‐
sion
1.0
to
2.0
or
higher,
all
device
spe‐
cial
files
asso‐
ci‐
ated
with
the
vg_name
may
get
recre‐
ated.
The
appli‐
ca‐
tions
need
to
take
care
of
recre‐
at‐
ing
the
sym‐
links
or
hardlinks
to
the
new
device
spe‐
cial
files
of
the
vol‐
ume
group
vg_name
post
suc‐
cess‐
ful
migra‐
tion.
FILES
Holds
the
exist‐
ing
vol‐
ume
group
con‐
fig‐
u‐
ra‐
tion
hav‐
ing
vol‐
ume
group
ver‐
sion vg_ver‐
sion_old.
This
file
con‐
tains
the
exist‐
ing
vol‐
ume
group
con‐
fig‐
u‐
ra‐
tion
of
vol‐
ume
group
ver‐
sion vg_ver‐
sion_new.
Holds
the
map‐
file
infor‐
ma‐
tion
for
the
orig‐
i‐
nal
vol‐
ume
group. This
file
con‐
tains
the
names
of
log‐
i‐
cal
vol‐
umes
of
the
vol‐
ume
group.
Holds
the
map‐
file
infor‐
ma‐
tion
for
the
vol‐
ume
group
ver‐
sion vg_ver‐
sion_new.
This
file
con‐
tains
the
names
of
log‐
i‐
cal
vol‐
umes
of
the
vol‐
ume
group.
Holds
the
list
of
phys‐
i‐
cal
vol‐
umes
in
the
vol‐
ume
group. The
order
of
phys‐
i‐
cal
vol‐
umes
is
decided
by
the
order
in
which
they
are
added
in
the
or
A
script
cre‐
ated
by before
mak‐
ing
any
update,
to
be
used
if
the
com‐
mand
is
inter‐
rupted
while
com‐
mit‐
ting
the
con‐
fig‐
u‐
ra‐
tion
changes
to
the
phys‐
i‐
cal
vol‐
umes.
See
the
sec‐
tion
for
its
usage.
SEE ALSOboot(1M),
lvln‐
boot(1M),
mkboot(1M),
pvcre‐
ate(1M),
pvmove(1M),
vgcfg‐
backup(1M),
vgcf‐
gre‐
store(1M),
vgchange(1M),
vgcre‐
ate(1M),
vgdis‐
play(1M),
vgex‐
tend(1M),
vgmod‐
ify(1M),
vgre‐
duce(1M),
lvm(7).
vgversion(1M)
