Articles on: DATA MIGRATION

Why is the destination volume not mountable during migration?

By design, CMC has an Accidental Data Access Protection mechanism to prevent unintended data corruption to the migrated data.

Issue


While migration is in progress, the destination volume cannot be mounted.

Explanation


This behavior is by design. CMC has a Accidental Data Access Protection mechanism to prevent unintended data corruption to the migrated data.
During different phases of the migration process, CMC ensures that OS or application only have access to the correct copy of the data, as follows:

Initial Synchronization

Only source data is accessible by applications. The destination disk partition is scrambled to prevent accidental usage.

Periodic Re-Synchronization

Only source data is accessible by applications. The destination disk partition is scrambled to prevent accidental usage.

cMotion™

Source host application continues to access data via redirection by CMC driver to the destination disk. This implies destination disk is more up-to-date than the source disk, and to avoid accidental use of source disk by the application in the case where the redirection is no longer in effect (such as when driver is forcefully unloaded or prohibited to be loaded on a reboot), it is critical to make sure the source disk is NOT usable.

This is done by scrambling the source disk partition. Therefore:

At the cMotion™ state, both source and destination volumes are scrambled at-rest and are only accessible through redirection by the driver via the source block device in order to ensure only the destination disk is visible to the application. In rare cases such as catastrophic events where the CMC driver is no longer installed but the destination disk has to be accessed, follow steps below to manually descramble a disk.

Finalize Cutover

This state is the same as the cMotion state above, except that the destination disk is unscrambled at rest. The source host applications continues to access the source disk entity which is redirected to the destination disk. Even though the destination disk is unscrambled and it is possible to online the disk (for Windows) or mount the disk (for Linux) this MUST not happen because any writes to the source disk entity is still being redirected to the destination disk. The descrambling of the destination disk at this state is for two reasons:

First, for zero-down-time cutover of clustered disks, this allows the destination disks to be accessible by the other active node(s) of the cluster after the CMC node (the node that was active and has CMC agent installed) is set offline for remediation. See this article for the detail step-by-step Windows cluster cutover procedure: https://support.cirrusdata.cloud/en/article/howto-migration-for-microsoft-windows-multi-node-cluster-q7vhwc/.

Second, in the case where there is an immediate need to make use of the destination disks (faster, more reliable, etc) but there is no downtime available until days or months later, the "Finalized Cutover" state allows for indefinite deferment of the downtime. In this state, the I/O to the source device entity is being redirected to the destination. The source disk is actually no longer being used. If a planned or unplanned reboot happened in this state, the CMC driver will automatically complete the final cutover by no longer redirecting. Because the source disk is scrambled, it will not be visible to the OS, and only the destination disk is accessible by the OS and is the one that will be mounted into production use.

Snapshots / Manual Descramble


However there are times where it is desirable to descramble a scrambled volume. For example, to make use of a snapshot clone of the destination volume which are scrambled if the snapshot was taken prior to Finalize Cutover, you will need to first manually descramble the data.

A separate utility is available for this purpose - manually descramble any block devices. After successful descrambling (within seconds), the volume can then be mounted without errors.

Warning! To avoid data corruption, DO NOT run this utility on any volumes that is currently in any migration sessions

Linux



[root@cds-centos75-c001 ~]# mtdi descramble /dev/sdd
Device /dev/sdd data will be modified [y/n]: y
device  /dev/sdd  descrambled successfully

Windows


Open cmd.exe or PowerShell as administrator and run the following command:
PS C:\Program Files\CirrusData\mtdi> .\mtdi.exe descramble \\.\PhysicalDrive1
Device \\.\PhysicalDrive1 data will be modified [y/n]: y
device  \\.\PhysicalDrive1  descrambled successfully

Updated on: 20/12/2022

Was this article helpful?

Share your feedback

Cancel

Thank you!