Data consistency issues after migration - Server Migration Center

This topic describes the data and system configuration changes that occur after a server migration and provides guidance on post-migration adjustments.

Data consistency issues for Linux instances after migration

System configuration changes

Server Migration Center (SMC) makes the following changes to ensure that the migrated server runs properly on ECS. These changes do not affect the services on the source server.

Automated change	Reason
Fix boot files	Affected files: /boot/grub/grub.conf, /boot/grub/grub.cfg, or /boot/grub2/grub.cfg The system disk UUID is replaced to allow the operating system to detect and boot from the system disk.
Fix automatic mount configuration file	Affected file: etc/fstab This allows data disks to be correctly detected and automatically mounted after the instance starts.
Disable SELinux	Affected file: /etc/selinux/config SELinux is disabled to prevent its strict access control mechanisms from causing application startup failures. If your applications require SELinux, you can re-enable it after assessing the security impact post-migration.
Fix cloud-init configuration	Affected file: /etc/cloud/cloud.cfg This allows the migrated instance to receive and execute initialization configurations from the cloud platform.
Rebuild initramfs	Affected file: /boot/initramfs*.img This installs necessary drivers for the cloud environment, such as the virtio driver.
Install dependencies	To ensure block replication is enabled, the following dependencies for the block replication component are installed: gcc and make.
Install and run the SMC client	The default installation directory for the SMC client is `/smc`.

The following configuration items require manual changes.

Issue

Cause

Failure to use an SSH tool to remotely log on to the instance.

SMC copies the network interface card (NIC) configuration file from the source server. After migration, the original NIC name may not match the standard naming convention required by ECS (such as eth0 or eth1), which can prevent the network service from starting correctly. You must manually modify the configuration and restart the service.

The following example shows how to change the source NIC name from ens192 to eth0. Modify the name as needed:

Log on to the migrated ECS instance.
To migrate to an image, you must first create an instance from a custom image or a shared image.
1. Go to ECS console - Instances. In the top navigation bar, select the target region and resource group.
2. Go to the Instance page. Click Connect in the actions column, then click Sign in now in the dialog box that appears. Log in as prompted to go to the terminal page.
Run cd /etc/sysconfig/network-scripts/ to go to the NIC configuration directory.
Find the NIC configuration file ifcfg-ens192 and rename it by running sudo mv ifcfg-ens192 ifcfg-eth0.
Run sudo vi ifcfg-eth0. Change the DEVICE parameter to eth0 and the BOOTPROTO parameter to dhcp. Then, save the file and exit.

Restart the network service for the configuration to take effect.

Operating system	Command to restart the network service
Alibaba Cloud Linux 2 CentOS 7 Red Hat 7 Anolis 7 SUSE Linux 11, SUSE Linux 12, and SUSE Linux 15 openSUSE 15 and openSUSE 42	`sudo service network restart` or `sudo systemctl restart network`
CentOS 6 Red Hat 6	`sudo service network restart`
Alibaba Cloud Linux 3 CentOS 8 Red Hat 8 Anolis 8 Fedora 33, Fedora 34, and Fedora 35	`sudo systemctl restart NetworkManager` or `sudo reboot`
Ubuntu 18, Ubuntu 20, and Ubuntu 22 Debian 12	`sudo netplan apply`
Ubuntu 14 and Ubuntu 16 Debian 8, Debian 9, Debian 10, and Debian 11	`sudo systemctl restart networking` or `sudo reboot`

The hostname changes.

The hostname is changed during the migration. You can reconfigure it to the desired name.

Failure to log on with the original password.

The original password is no longer valid after the migration.

Migration to an image: When you create an instance from a custom image or shared image, you can customize the logon password in the Logon Credentials section on the purchase page.
Migrating to an ECS instance: Reset the password.

Storage and data changes

Issue	Reason
Disk device name changes	Logical Volume Manager (LVM) logical volumes that span multiple disks are converted to regular partitions. SMC supports copying LVM structures only when they are on a single disk. For volume groups (VGs) or logical volumes (LVs) on multiple disks, the original LVM structure cannot be retained. The logical volume, such as /dev/mapper/test-lvm1, is migrated as a whole to a regular partition, such as /dev/vdb1, on a cloud disk. The data is retained. The storage device name on the source server may change after migration. If the source device name is an NVMe or sda type, it changes to the NVMe type on an Alibaba Cloud instance with an NVMe drive, or to the vda type on an instance with a virtio drive. This is normal and does not affect usage.
The size displayed by the `du` command is smaller than the size displayed by `ls -l`	By default, SMC migration uses the '--sparse' optimization option. This option ensures that sparse files on the target instance occupy only the physical space required for their actual data. Sparse files have a logical size that is larger than the physical space they occupy. This behavior does not affect normal use. To perform a full copy of sparse files, add '--no-S' to the 'sync.options' parameter in the 'client_data' file and then restart the migration.
Data inconsistency after migration	Services are not stopped during migration. Data inconsistency can occur if services are writing data during the migration. To ensure data consistency, stop all write operations to the disk before you start the migration. File filtering rules are set. By default, SMC is configured to filter out certain files and directories from the migration. Temporary files are not migrated. SMC does not migrate temporary files, such as virtual memory files, cache files, or temporary backup snapshot data. The file system is rebuilt. When you use file-based copy for migration, the file system of the partition is rebuilt. The file system metadata, such as inode size and storage format, may change. Consequently, the reported used disk space may differ by up to 10% after the migration.
Docker environment lost	SMC supports a full migration of the Docker environment only when you use block replication. For more information, see Considerations for enabling block replication.

Data consistency issues for Windows instances after migration

System configuration changes

Issue	Solution
Hostname changes	The hostname changes after the migration. You can configure it again.
Invalid original logon password	The logon password is changed after the migration. Migrate to an image: When you create an instance using a custom image or a shared image, you can set the logon password in the Logon Credentials section on the purchase page. Migrate to an ECS instance: Reset password.
Install and run the SMC client	The default installation directory for the SMC client is `C:\smc`.

Storage and data changes

Issue	Reason
Drive letter changes	On the first boot, the Windows operating system redetects storage devices and assigns drive letters sequentially. This may cause the drive letters to be different from those before the migration. You can manually change the drive letters. Log on to the migrated ECS instance. If you are migrating to an image, you must first create an instance from a custom image or a shared image. Go to ECS console - Instances. In the top navigation bar, select the target region and resource group. Go to the Instance page. Click Connect in the actions column, then click Sign in now in the dialog box that appears. Select Terminal for Connection Method, enter your username and password, then log in. On the Windows Server desktop, right-click the icon and select Disk Management. In the Disk Management interface, right-click the target volume and select Change Drive Letter and Paths from the pop-up menu. Follow the on-screen instructions.
A GPT partition becomes an MBR partition	This change does not affect data read and write operations on the partition. To maximize compatibility, when SMC migrates a data disk smaller than 2 TiB, it converts the partition table format from GPT to MBR. To scale out the disk to more than 2 TiB in the future, you must transform the partition to a GPT partition.
The dynamic disk structure is not copied	SMC does not support migrating the structure of Windows dynamic disks. After migration, dynamic disks from the source server are converted into basic disks.