HP 3PAR Peer Motion Guide

New volume has now been migrated from old primary to new primary, and remote copy
re-established.
*This will only operate with mvar rcopy_snap_vv_init set to 1: tcli --exec 'mvar set
-n rcopy_snap_vv_init -v 1'
Migration of a Secondary System
The following details migrating from B to C, where B is currently acting as a secondary volume for
A. During a Peer Motion migration, no data can be written to the original volume (in this case, B).
For the secondary, migration is done from a snapshot, which allows for maintaining an active
secondary at all times.
Figure 15 Secondary system migration
A) Primary: <primary_vv>
B) Old Secondary: <old_secondary_vv>
C) New Secondary: <new_secondary_vv>
Remote copy group: RCPM_Group
New RC group: New_PM_Group
NOTE: The following assumes that C has been configured as a host for B. See “Migration of a
Primary System” (page 85) for details.
1. On A, ensure no resyncs are running. Once any remaining syncs complete, stop the RC group
and take snapshots of the primary and secondary VVs:
• stoprcopygroup RCPM_Group
2. When an RC group stops, it creates a snapshot of the VV. Create a copy of the most recent
snapshot. The showvv displays the most recent snapshot, usually named, rcopy.xx.YYYY.zz,
where YYYY is the ID of the VV. Use showrcopy –d for more information.
• createsv RCPM_ResumeSS rcopy.xx.YYYY.zz
3. On B:
• createsv <old_secondary_vv_SS> <old_secondary_vv>
4. Export the snapshot to C as a disk.
• createvlun <old_secondary_vv_SS> 1 C
5. On C: When exported, rescan the bus and admit the volume. Where 2FF70002AC000091
is the Node_WWW shown and 50002AC003E80091 is the Lun_WWW of the disk.
• showtarget -rescan
• showtarget
• showtarget -lun 2FF70002AC000091
Migration of a Secondary System 87