vgversion.1m (2010 09)

v
vgversion(1M) vgversion(1M)
2) Do the actual migration of the volume group vg_name :
• Appropriate recovery check points are created on the system by the
vgversion command, as
part of the migration, to support recovery following 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
vgversion_vg_name_restore
with the volume group vg_name configuration file vg_name_vg_version_old
.conf available on the
system to restore the volume group vg_name to the original volume group version:
• The
vgversion command was interrupted while migration was in progress
• Post successful migration to vg_version_new using the
vgversion
command.
The
vgversion 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 version vg_version_new metadata.
• All the current LVM configuration and characteristics of the existing volume group vg_name and its
logical volumes and physical volumes are supported by the volume group version vg_version_new.
The
vgversion command is supported only on deactivated volume groups, but user can review the
migration when the vg_name is active. All physical volumes that belong to volume group vg_name must
be available while performing the migration.
The volume group must be cluster unaware (use
vgchange -c n if vg_name were cluster aware) before
migration is made. The vgversion 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,
vgversion creates the following
files under the /etc/lvmconf/vgversion_
vg_name directory in preparation of migration to volume
group version vg_version_new:
• A restore script,
vgversion_vg_name_restore, 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 vg_name_vg_version_old
.conf 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, vg_name_vg_version_new
.conf, 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 version vg_version_new using the restore script.
• A disks_file, vg_name
_disks, 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 /etc/lvmtab or
/etc/lvmtab_p. This file is generated to be used by the restore script.
• A mapfile,
mapfile_vg_name_2.x, 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,
mapfile_vg_name_1.0, 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 gen-
erated to be used by the restore script.
Note: All the above files created during the
vgversion command, continues to exist on the system at
the /etc/lvmconf/vgversion_vg_name 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 cau-
tion 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 volume 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, metadata is not restricted to an extent. The LVM metadata for volume
2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: September 2010