vxmigadm - online migration of native LVM volumes to VxVM volumes

vxmigadm [-v] [-L logfile] [-t type] [-S] analyze -g grpname [-l vol_list]

vxmigadm [-v] [-L logfile] [-t type] start -g grpname [-l vol_list]

vxmigadm [-v] [-L logfile] recover

vxmigadm [-v] [-L logfile] status -g grpname [-l vol_list]

vxmigadm [-v] [-L logfile] [-t type] [-f] commit -g grpname [-l vol_list]

vxmigadm [-v] [-L logfile] [-t type] abort -g grpname [-l vol_list]

The vxmigadm command performs administration for the online migration of native LVM volumes to VxVM volumes, with limited application downtime. This command is available in the /etc/vx/bin, /opt/VRTS/bin, and /usr/lib/vxvm/bin directories.

To prepare for migration, create target VxVM diskgroups and volumes on the new storage added to the application host. Veritas recommends that you migrate all the storage to DMP control.

See the ’Prerequisites for online migration from LVM to VxVM’ sections in the
Veritas InfoScale™ Solutions Guide, to meet all the prerequisites.

Before starting migration, you can perform sanity analysis through the analyze operation. Once the analysis is successful, you can start migration using the start operation. This needs application shutdown for a limited time across the start operation. You can track the data synchronization progressing in the background through the status operation. You can use the recover operation to recover the live migration configuration in case of a system reboot. Once the data synchronization is completed for all required volumes, you can commit migration using the commit operation. In case of any errors, you can abort the migration and revert to the original configuration using the abort operation. You need to shut down the application during the abort operation.

You can also perform online migration in VCS high-availability environment, with failover type service group. VCS monitors and maintains high availability of the updated configuration during the migration process. Standard VCS operations like service group offline, online, switch, failover can be done as usual. You need to execute the vxmigadm commands on the node having the LVM volume group’s service group online. vxmigadm automatically detects the source LVM configuration type, and accordingly performs the required actions for it.

The vxmigadm arguments indicate the input-set, specified with the original source or target names. This can be a volume group, or a subset of volumes in a volume group. This input-set comprises of the volume group or volumes required by the application, and must be the same for all operations intended on that set.

-g grpname: The volume Group for the operation.

-l vol_list: space-separated list of volumes in the given volume group, for the operation. If not specified, all volumes of the volume group are selected.

analyze
	To do analysis prior to the start operation. Conducts sanity checks for the LVM and VxVM configuration intended for migration, and displays the detected irregularities, if any. Performs checks for the environment, source volume group, source volumes, target diskgroup, and target volumes. You need to fix the detected irregularities, and re-run the analyze operation until no errors are reported. In VCS HA environment, it also performs VCS sanity checks. Use the -S option to execute analyze on all standby nodes not having the SG online.
start	To start migration, after the analyze operation is successful. Application should be shutdown before executing the start operation. Sets up the migration configuration, by adding the LVM volume as a source mirror, and the VxVM volume plex(es) as the target mirror(s). Starts data synchronization from LVM to VxVM volumes, in the background. The application, when resumed, works with the target VxVM volumes through the original LVM volume device paths. Source LVM volumes are renamed to <lvolname>_vxlv, and are kept up to date till migration is committed or aborted. Additionally in VCS HA environment, the VxVM resources are added and dependencies are updated so that application will depend on both LVM and VxVM resources.
recover
	To recover migration configuration post reboot, before it is committed or aborted. Recovers all existing migration configurations on the system after a crash or reboot. The usual VxVM recovery procedures apply for any other disturbances. In VCS HA environment, the required recovery is internally done by VCS.
status	To track the data synchronization status details, for a live migration setup before commit or abort. For the volumes in progress, it shows the task-id, percentage of completion, and task-status. Also shows the current configuration type.
commit	To commit the migration, after status operation indicates that data synchronization is complete for all the required volumes. Dissociates the LVM configuration from the migration setup, resulting into exclusive VxVM configuration. The application continues to use the target VxVM volumes through the original LVM volume device paths. Source LVM volumes are retained with renamed names as <lvolname>_vxlv. The LVM volumes have data up to the commit point, and are not updated any further. The -f option must be specified to force the commit operation, when the FastResync license is not available, or if the VxVM volumes have the DCO version lower than 20. Before forced commit, the application needs to be shutdown if application data consistency is required for the source LVM volumes. Additionally in VCS HA environment, the resources and dependencies are updated so that the application depends only on VxVM resources. The LVM resources are still present in the service group, but are disconnected from the application resource tree, and marked non-critical.
abort	To abort the migration in case of errors, before the point of commit. Application should be shutdown before executing the abort operation. This restores the LVM and VxVM configurations to their original state. The application, when resumed, works with the source LVM volumes through the original LVM volume device paths. The source LVM volumes contain data up to the abort point. Additionally in VCS HA environment, the VxVM resources are removed and original VCS resource dependencies are restored, so that the application depends only on LVM resources.

-v	Outputs verbose messages indicating the major operations being performed and the milestones reached. This gives an indication of the progress being made.
-L logfile
	Specifies a logfile to log the details of operation execution. If not specified, the default is /var/adm/vx/vxmigadm.log. The vxmigadm.log file can also be accessed through/etc/vx/log.
-t type	Specifies the intended configuration type, either STANDALONE or SFHA. Internally detected configuration type is used, if not specified. Valid for the analyze, start, abort, and commit operations.

See the ’Best practices for online migration from LVM to VxVM’ sections in the
Veritas InfoScale™ Solutions Guide, for Do\(cqs and Don\(cqts.

To analyze all volumes in the volume group mygrp, using the verbose option and user-specified logfile:

vxmigadm -v -L /mydir/mylog.out analyze -g mygrp

To analyze a set of volumes vol1 and vol2 in the volume group mygrp:

vxmigadm analyze -g mygrp -l vol1 vol2

To start migration for volumes vol1 and vol2 in the volume group myvg:

vxmigadm start -g mygrp -l vol1 vol2

To recover existing migration configurations post reboot:

vxmigadm recover

To track data synchronization for volumes vol1 and vol2 in the volume group myvg:

vxmigadm status -g mygrp -l vol1 vol2

To commit migration for volumes vol1 and vol2 in the volume group myvg:

vxmigadm commit -g mygrp -l vol1 vol2

To abort migration for volumes vol1 and vol2 in the volume group myvg:

vxmigadm abort -g mygrp -l vol1 vol2

vxintro(1M), vxdisk(1M), vxdg(1M), vxassist(1M), vxsnap(1M), vxdctl(1M), vxprint(1M), vxtask(1M), vxdefault(1M), vxconfigd(1M), lsvg, lslv, chvg, chlv.

Veritas InfoScale™ Solutions Guide