LVM Migration from Legacy to Agile Naming Model

Following the invocation of vgscan -B command, use vgchange to reactivate the corresponding volume group.
This reconfigures the volume group with the DSFs (both legacy and persistent DSFs corresponding to each of
the physical volume) in the /etc/lvmtab file. Legacy DSFs can later be removed using vgreduce, leaving
behind corresponding persistent DSFs. This facilitates a phased DSF migration from legacy to agile naming
model, while the volume group continues to remain active.
Backup the /etc/lvmpvg file, if it exists. After the vgreduce operations, restore the backed-up /etc/lvmpvg file
and replace legacy DSFs listed under the volume group being migrated with corresponding persistent DSFs (In
case of multi-path devices, a single persistent DSF can correspond to multiple legacy DSFs). Persistent DSFs,
corresponding to legacy DSFs, can be found using ioscan –m dsf <legacy_dsf> command.
3. A shell script /usr/contrib/bin/vgdsf, can be used to perform the DSF migration of a given volume group.
vgdsf uses existing LVM commands - vgdisplay, pvdisplay, vgextend and vgreduce, in addition to the ioscan
command to perform the DSF migration. It automatically updates both the /etc/lvmtab and /etc/lvmpvg files
to reflect the newer configuration and no additional user action is required. The use of the vgdsf script
simplifies the DSF migration operation and the volume group can remain active and in use.
4. The vgdsf script is a wrapper script around existing LVM and I/O commands. Hence, the same functionality
can also be achieved by the direct use of these commands. The operation and the steps can be followed by
viewing the vgdsf script (briefly explained in the later sections of this paper). This alternative provides a user,
control over the DSF migration operation. (Remember to use vgextend with –g option in order to preserve the
PVG configuration.)
Note: The above methods (except for the vgdsf script in
alternative 3) can also be used to migrate volume group
configurations back to the legacy naming model.
Migration of a Clustered Volume Group
To migrate volume groups used in a Serviceguard cluster, each volume group must be either inactive, or active on
only one node in the cluster. The volume group must be migrated on each node. It is possible, though not a best
practice, to use legacy DSFs on some nodes after migrating to agile addressing on others; this allows you to
migrate different nodes at different times, if necessary.
On nodes where the volume group is not active, alternatives
1 and 2 can be used to migrate the volume group
(shared and non-shared).
Additional steps need to be taken before vgdsf can be used to migrate volume groups shared by Serviceguard
cluster. The activation mode must be switched to "exclusive" on the node where the volume group is active. vgdsf
can then be run on this node to migrate the volume group. Then, method
1 or 2 should be used to migrate the
volume group on the remaining nodes whilst still deactivated. Then the volume group is switched back to
"shared" mode on this node and reactivated on all nodes.
Migration using vgdsf
To simplify migration of volume groups, a user script – vgdsf, is made available.
The vgdsf script performs the following tasks. Read the script for a more complete understanding.
1. Extend the volume group with corresponding persistent DSFs:
9