Step-by-step Procedure for Cutover of Linux Disks

Step-by-Step Procedure for Migration and Cutover of Linux Disks

Note: This procedure is for migration of Linux server physical disks visible in the output of lsblk. These disks are used with mkfs where the filesystem is created on the entire disk (non-partitioned) or a partition. Read How to migrate LVM volumes on Linux for disks that are physical disk extends of an LVM. Please check back later for the updated document.

Create a Migration Session after selecting one or multiple source disk (not the boot disk) and pairing each with a new destination disk that is created either manually or with the Integration. Both the source disk and the destination disk should be listed in lsblk. The pictures below shows source /dev/sdb being migrated to destination /dev/dm-0. Throughout the migration process, the destination disk is “masked” or “scrambled” such that it cannot be mounted.

When the initial sync of the disk is complete (100%), the status becomes "Tracking Changes" as in picture below. It is ready for the next step for cutover. At this point, the Source Disks are not yet masked, and the Destination Disks are masked.

The “Tracking Changes” state can be maintained indefinitely until there is an application downtime window to complete the cutover. For cluster disks, the downtime can be avoided using the Cluster Cutover Procedure How to Migrate and Cutover Linux Clusters without Downtime. For non-cluster applications, wait for available downtime window for the next steps.
 Please check back later for the updated document.

When downtime is available for final cutover, at CMC Project->Migration Session page, use the red "SESSION ACTIONS" button to "Trigger cMotion". Application I/O at the source is now redirected to the Destination Disks. At this point, the destination disk is being updated while the source is no longer. This can be reverted using the “SESSION ACTIONS” button to select “Revert cMotion” if there is a reason to undo the cMotion. After cMotion, both the Source and Destination Disk are masked, but source continues to be accessible through redirection to the destination. Other than for cutover of cluster disks, proceed immediately to the next steps to complete the cutover.

Use "SESSION ACTIONS" button to trigger "Finalize Cutover". This will unmask (descramble) the Destination Disks. The Destination Disks at this point are actually being updated by the Redirection process of CMC. The Source disks appears to be mounted and is accessible logically but the underlying physical disk is no longer updated when cMotion was triggered back in step 3 above. It is VERY IMPORTANT not to mount the destination at this point. YOU MUST UNMOUNT THE SOURCE VOLUME first otherwise the destination may be corrupt due to “double mounting” by proceeding to Step 5.

It is worth noting that it is perfectly normal to stay at this state for extended period of time while waiting for Application downtime in order to perform step 5 and beyond. This allows the new disk, presumably faster and more reliable, to be put into production use prior to having downtime. In this state the source disk is completely bypassed due to redirection to the Destination. At this point, a reboot of the system, intentional or not, will result in the source disk being inaccessible (due to masking) and the destination disk being accessible and assigned the same volume-level uuid (if a filesystem is created) or the same lvm VG/LV identity. If the fstab reference for auto-mount uses volume UUID (as in the output of 'ls -l /dev/disks/by-uuid' ) or using VG/LV reference, the mount-point is automatically activated and applications can auto-start once the system boots up. This, essentially, completes the final cutover. If a reboot should happen, the redirection will no longer be active when the system boots up. Clean up by deleting the migration session and skip to step 7 below if this should happen.

Offline the application, and unmount the source disk. You MUST be able to unmount the source disks from their mount-points, otherwise the destination disks may have problem being mounted due to conflicts. If you are not able to unmount, it could mean that the Application is not fully stopped, or that some other user or ssh session is in the directory that is par with the mount-point. Use ‘lsof’ to verify, and if still unable to unmount, your last recourse may be to reboot and proceed to Step 7. Unless you are able to unmount the source disk, DO NOT mount the destination as this will result in double-mount.

Use “SESSION ACTIONS” button to [Complete Session]. This stops the redirection without having to reboot. This is the reason why the source disks must be unmount before this step. Essentially if they were still mounted, there will be an I/O outage. The source disks are also scrambled at this point to prevent confusion and mounting old data. Optionally: delete the migration session.

If the source disks were externally attached disks, remove/detach them and rescan to ensure they disappeared from lsblk.

Mount the destination disks to their respective mount-points. If fstab were used to auto-mount, please make sure to use non-physical references (such as /dev/sde), and use the logical references (such as uuid=xxxxxx where xxxxx is output of ls -l /dev/disks/by-uuid or lvm references such as vg1/lv5). For iSCSI or other external disks, it is recommended to change the mount options to 'default, no fails'.

Note: After the above migration and cutover procedure, the Source Disks are masked and no longer appear to have a partition. The data is still on the disk. If you wish to access the disks, see article How to unmask a disk that is masked by CMC migration.

Updated on: 19/12/2022

Was this article helpful?

Share your feedback


Thank you!