Cloud Migration Service (CT-CMS)

Server Migration Module

2024-12-27 03:00:34

1.1.1 Product Consulting

1.1.1.1 What are the application scenarios of the CMS?

When you need to migrate on-premises servers or servers of other cloud service providers to eSurfing Cloud, you can use the CMS to orderly, securely, conveniently and easily migrate digital assets, services, IT resources and applications to eSurfing Cloud, in part or in full, while ensuring the availability, security and continuity of applications on the cloud.

1.1.1.2 Does the CMS support migration from Alibaba Cloud, eSurfing Cloud, and other cloud platforms to eSurfing Cloud?

Yes.

The CMS supports migration from mainstream cloud service providers in the market to eSurfing Cloud, such as Alibaba Cloud, eSurfing Cloud, AWS, and China Mobile Cloud.

It also supports the migration of local elastic cloud servers to eSurfing Cloud. In general, resources using the same processor architecture can be migrated to eSurfing Cloud using the CMS service.

1.1.1.3 Does the CMS support the migration of elastic cloud servers on eSurfing Cloud to other cloud service providers or on-premises servers?

No.

For the CMS service, you can only select eSurfing Cloud as the migration target and thus you cannot migrate eSurfing Cloud ECS to an on-premises server or other cloud service providers.

1.1.1.4 Can I ask eSurfing Cloud engineers to help me with the migration when I use the CMS service?

eSurfing Cloud engineers are not directly involved in your business migration. You can conduct your migration by referring to Help Center.

If your issues are not mentioned in the Help Center, you can submit your issues on the page, and our engineers will provide supplementary content later.

If you need professional migration solutions and customized technical support, you can order our migration services to help you smoothly migrate applications, shorten the downtime, reduce the impact of cloud migration on your business continuity, relieve your concerns on cloud migration, and focus on business development.

1.1.1.5 Can resources be migrated to GPU image acceleration basic type, GPU computing accelerated, and bare metal cloud servers?

GPU Image Acceleration Basic Type

Yes.

GPU Computing Accelerated

Yes.

Bare Metal Cloud Server

No.

1.1.1.6 Does the CMS support resumable transfer?

Yes.

When data transmission is interrupted due to network exception, the transmission can be automatically resumed after the network resumes normal operation.

When the CMS-Agent is interrupted due to misoperations, run the CMS-Agent again and restart the migration task to continue the migration.

1.1.1.7 Does the CMS support incremental data migration?

Yes.

The basic migration form of the CMS is full data migration + incremental data migration (manual/cyclic incremental data migration).

1.1.1.8 How do I migrate an ECS from one account to another?

When you need to migrate resources from Account A to Account B, you must follow the following steps:

1. In the ECS of Account A, use Account B's AK/SK to install the CMS-Agent.

2. The ECS of Account A will be reported to the migration platform of Account B. Then complete the subsequent migration operations to migrate the ECS across accounts.

For more information on steps, see Best Practices for Migration Between eSurfing Cloud ECS Instances.

1.1.1.9 How to migrate an ECS from one region to another region?

When you need to migrate resources from Region A to Region B, you must follow the following steps:

1. Use the cloud migration service in Region B.

2. Install the CMS-Agent on the ECS in Region A and report the migration source.

3. Create the target server in Region B and then complete the subsequent migration operations to migrate the ECS across regions.

For more information on steps, see Best Practices for Migration Between eSurfing Cloud ECS Instances.

1.1.1.10 Why is the account balance limited to more than 100 for this free-of-charge service?

The CMS is free of charge, but pay-as-you-go resources are created and fees are incurred during the migration. For more information, see Billing.

1.1.1.11 Are applications on the migration source affected during migration?

Applications on the migration source are not affected under reasonable loads. The migration program consumes few resources and does not affect applications.

However, when the migration source runs with a high load, you must limit the bandwidth and CPU usage of the CMS-Agent to reduce the usage of the source server by the CMS-Agent to avoid adverse impact on applications on the source server.

1.1.1.12 Is the AK/SK installed during migration the same as that of eSurfing Cloud?

No.

The AK/SK for the CMS is independently developed and located under the Agent tab and used for verifying the installation of the CMS-Agent.

1.1.1.13 What is the role of CMS AK/SK?

The AK/SK contains the information necessary for the source server to register with the console, including the platform user information, the platform address, and the authorization code.

1.1.1.14 Will the CMS AK/SK change? Is there a time limit?

The CMS AK/SK changes.

The AK/SK is valid for one day. The AK/SK changes every time the page is refreshed.

1.1.1.15 Why does the CMS AK/SK change? Can I keep the AK/SK unchanged?

For security reasons, you cannot keep the AK/SK unchanged.

In essence, AK/SK represents a kind of identity authentication. The cloud platform verifies whether the CMS-Agent can register with the CMS service by authenticating the identity using the AK/SK, which is the most easily leaked but also the most sensitive data on the cloud, After users pass the AK/SK authentication, the migration source is successfully registered and reported and appears in the CMS server list. Then, you can view the information of the migration source and execute migration tasks.

If the AK/SK leaks, unauthorized devices may register with the CMS service. Therefore, dynamic AK/SK is required to reduce the risk of leakage.

1.1.1.16 Can a Linux user without the ROOT permission migrate resources?

No.

If migration is impossible in a Linux OS, the migration cannot be completely performed and the content to migrate may be missing.

1.1.1.17 What is the information of the migration source collected by the CMS?

In order to provide you with more accurate and better services, the Platform may collect and use the information you provide in the following ways, and the Platform will comply with the User Privacy Agreement when using the information.

Privacy data collection: Based on the basic requirements of service provisioning, the Platform will collect the following server information, including:

Information Collected

Content

Basic Info

Login time

Agent information

Server type, Agent version

Server information

Server name, firmware type, server time to live, server system, system type, system version, kernel version, CPU architecture, user rights, system directory, and file system.

IP information

NIC information, NIC name, NIC IPv4, NIC IPv6

Processor information

Processor name, number of processor cores, processor frequency, and processor cache

HDD info

Disk name, disk partition format, used space, disk size (MB)

Memory Info

Total memory (MB), remaining memory (MB), and memory usage

1.1.1.18 How to select an ECS image on the target server?

Select a dedicated image for cloud migration for your OS when creating an ECS or reinstalling a system.

 

1.1.1.19 How to create an ECS?

For details, see Create an ECS.

1.1.1.20 Does the CMS support the migration of bare metal servers?

The CMS does not support the migration of bare metal servers.

1.1.1.21 What is file migration?

File migration is the process of migrating files from one location or system to another.

In file migration, information such as the content, metadata, and properties of a file is copied, transferred, or moved to a new storage device, file system, application, or operating system.

Key considerations during file migration include data security, integrity, consistency, and accuracy. Professional migration tools and technologies are often used to help with file migration to guarantee data protection and transfer efficiency during the migration.

1.1.1.22 What are the differences between file migration and block migration?

File migration and block migration are two different data migration methods, and they have different characteristics and application scenarios. The following shows the differences:

Difference

File Migration

Block Migration

Data Unit

File migration moves an entire file from one location to another.

Block migration migrates data blocks on a storage device.

Granularity

File migration manipulates file systems and file structures at a higher level and deals with file-level metadata.

Block migration reads and copies data blocks on storage devices at a lower level without involving file systems and file structures.

Applicability

Applicable for data migration between file systems, or migration of files from one application or operating system to another.

Applicable to data replication and backup at the storage device level.

In summary, file migration is suitable for high-level file system migration and application migration and features high flexibility. Block migration is applicable to data replication and backup at the storage device level and features higher efficiency and ensures data consistency. The selection of a migration mode depends on your specific needs, resources, and environment requirements.

1.1.1.23 Why is CMS based on file migration and what are the advantages of file migration?

File migration features high flexibility and operability. You can selectively migrate, copy, or delete files for easy file management and operation.

File migration migrates files and generally features ease of understanding and higher readability.

File migration allows data management and operations at a higher level, such as file-level permissions, metadata, and so on.

1.1.1.24 What is a valid file?

Computer files are a collection of information stored on the HDD of a computer, which can be texts, pictures, programs, and so on. For example, system files, user files, and library files when being classified by nature and purpose, or temporary files, permanent files, and archival files when being classified by the retention period of information.

The CMS automatically filters out files of shared storage type. Valid files are computer files except logs and temp files.

1.1.1.25 What are the differences between the CMS and traditional image migration?

The CMS uses the full data migration + cyclic incremental synchronization mode to implement second-level switchover, ensuring that applications are not interrupted during cloud migration. That is, applications are migrated in the background.

The CMS can also resume normal operation upon a network failure and restart, effectively preventing service interruption due to network failures or misoperations on Agent and guaranteeing operational stability.

Traditional image migration refers to a method of migration using the image technology in a data center or server environment. In traditional image migration, the full image of the source server (including the operating system, applications, configuration, and data) is copied to the target server and thus the entire system is migrated and deployed. When image migration starts, you must disable applications on the source server and transfer the entire image as a package. Applications stop during transfer. That is, image migration features long downtime, complicated operations, and high resource consumption.

1.1.1.26 Why the image displayed in CT-ECS details after cloud migration is named the image dedicated for xx- migration instead of the name of the source server system?

This is a normal phenomenon.

When the migration is complete, the name displayed in the Specification/Image column in the ECS console is the image name selected when an ECS VM is created, instead of the name of the current operating system.

1.1.1.27 How do I determine whether a migration task is complete?

In the CMS console, you can find that the console displays "The target server is recovered", and you can view the record report in the historical task. You can also check whether it is the migration source system after the target system is restarted upon boot repair.

1.1.1.28 Does the CMS support the migration of partial applications on the migration source to the cloud?

No.

The CMS is a migration service based on the operating system. You cannot migrate partial applications on the migration source.

1.1.1.29 Can the operating system of the migration target be inconsistent with that of the migration source?

No.

The CMS is a migration service based on the operating system. After the migration is complete, the attribute status of the target server must be the same as that of the source server.

1.1.1.30 Can I change the specification of the target server after the migration is complete?

Yes.

You can modify the specification of the target server as needed. When you downgrade the specification, check whether the service can bear the current applications. You must assume the responsibility if applications become unavailable due to specification downgrade. We recommend that you use recommended platform configurations for migration. For more information, see Create a Target Server.

Suggestion on storage capacity modification: For devices to be migrated, the CMS generally recommends that the partition configuration of the target server be the same as that of the source server.

We recommend that you do not reduce the capacity of the system disk. If you need to reduce the capacity of storage disks, use the following formula: Current disk capacity × disk usage × 1.5 (or space for redundant growth of one year).

To change the specification, you must manually change the configuration of the ECS. For more information, see Change Specification.

1.1.1.31 Can the migration proceed when eSurfing Cloud has no OS image on the source server or removes it?

Yes.

You can select a dedicated image for migration for the target server. You can proceed with the migration if the operating system of the source server is on the compatibility list.

1.1.1.32 What are the differences between the CMS and CT-IMS image service?

The CMS uses the full data migration + cyclic incremental synchronization mode to implement second-level switchover, ensuring that applications are not interrupted during cloud migration. That is, applications are migrated in the background. The CMS can also resume normal operation upon a network failure and restart, effectively preventing service interruption due to network failures or misoperations on Agent and guaranteeing operational stability.

When CT-IMS is used, creating an image may cause data loss if the ECS is not powered off and data is being read and written. Business continuity cannot be guaranteed when image migration proceeds in a shutdown state.

1.1.1.33 Can the newly generated data on the source server be migrated to the target server after the target server starts upon boot repair?

No.

The data on the target server is consistent with that on the source server upon boot repair. After the migration is complete, the target server system is no longer a dedicated system for migration, and migration is impossible. To synchronize data, you must migrate data again. Before the last incremental migration, ensure that applications on the source server stop and no new data is read or written.

1.1.1.34 How to create an ECS on the migration target server and what are the precautions?

For more information, see Create a Target Server.

1.1.1.35 Can the CMS migrate databases such as MySQL?

CMS is not recommended for large databases. Please use a professional database migration tool for migrating large databases instead. If you use a CMS for migration, you should stop the application process before the "Stop Incremental Synchronization" step.

1.1.1.36 Will the changes to commonly used ports on the migration source affect the migration?

No.

The CMS service has no special requirements for source ports. You do not have to open a specified port in the inbound direction. You only need to allow the port in the outbound direction.

1.1.1.37 How to access the CMS?

After logging in with your eSurfing Cloud account, you can go to Products > Security and Management > Management Tools > Cloud Migration in the upper left corner of the eSurfing Cloud homepage to access the CMS.

1.1.1.38 In what regions does the CMS provide services?

On any page in the Help Center, click First-class Node in the Select Region section at the top of the page to learn about more information.

1.1.1.39 How to configure compression settings in CMS task configuration? What is the default compression ratio?

After the source server is bound, click Compression Ratio (0 to 9) on the Configure Migration Task page to set the compression ratio.

The default compression ratio is 5 for Linux OS and 3 for Windows OS.

1.1.1.40 After the migration is complete, can the Windows OS and software activation licenses still be valid on the migration source?

No. Contact your software service provider for solutions.

After data such as systems, applications, and files on the source ECS is migrated to the target ECS, information such as ESC ID and MAC address of NIC changes. As a result, licenses for the operating system and applications become invalid. The CMS is not responsible for such issues. For the license for the Windows OS, you can use the license for eSurfing Cloud ECS to get a new license. For the licenses for applications, users must request new ones from their respective service providers.

1.1.1.41 Does the CMS allow users to set up the process to speed up migration?

No.

The CMS automatically plans threads based on the usage of the source server to prevent user misoperations. Manual intervention is not allowed.

1.1.1.42 Does the CMS only support x86 systems?

The CMS supports not only x86 systems but also ARM systems. For more information, see the Compatibility List.

1.1.1.43 How to decide the configuration of the eSurfing Cloud target server?

The memory of the target server must be greater than 4 GB. You are advised to use the same configuration for the target server as the migration source. If the memory of the migration source is less than 4 GB, increase the memory as needed after migration.

1.1.1.44 Can the CMS be used to migrate Oracle clusters or other clusters?

No.

After cloud migration, a cluster will become stand-alone. To use shared storage for Oracle RAC and ASM disks for some Oracle RAC, the migration tool cannot be used to migrate ASM disks or Oracle RAC.

1.1.1.45 Can CMS be used to migrate shared storage and object storage data?

No.

Shared storage features large data volumes and large data read and write changes. This may slow down the migration or frequently lead to an error. To avoid this problem, the CMS filters shared storage and object storage directories and informs you of the content that is filtered out on the page.

1.1.1.46 Are application personnel required to use the migration service?

Yes.

To maintain data consistency, users must stop businesses when using the product for incremental data migration.

Application personnel must stop services, and after businesses are migrated to the cloud, relevant personnel familiar with the businesses should test and verify the migration so as to reduce downtime.

1.1.1.47 What are the factors that will affect business start?

If the migration source involves unauthorized application software, pirated software, cluster database, U-Key hardware verification, and some hardware binding verification, businesses cannot normally start due to authentication problems such as authorization binding. Therefore, you must take precautions before migration.

1.1.1.48 What are the precautions regarding a network environment when using the CMS service?

If the migration speed reaches the upper threshold during migration, you should first test the source egress bandwidth as well as the inbound traffic bandwidth on the source server. Identify the existence of special networks, dedicated access, and public network environment.

1.1.1.49 Can the CMS fulfill specific requirements?

Yes.

The current CMS can meet specific requirements such as high-density scenarios and keeping IP addresses unchanged. If you have other specific requirements due to business needs, please submit a ticket for technical consulting.

1.1.1.50 What are the precautions when using the CMS for complex businesses?

You must record business information, and migrate, switch, and test business systems for associated businesses of the same type as needed.

1.1.1.51 What are the differences between migration in a Windows OS and in a Linux OS using the CMS?

The migration procedure in a Windows OS is different from that in a Linux OS. You must check the system version, close the anti-virus software, quit QEMU, and check the disk space (adjust the disk space of the volume shadow service if necessary).

1.1.1.52 What are the resource and performance limitations of the migration source?

The CMS agent is deployed on the source server and uses the CPU and memory of the source server. If the CPU or memory usage of the source server is too high, the CMS agent may affect business operations and even break down the migration source. Servers with 4 cores and 4 GPUs can meet resource migration requirements.

After the agent starts on the source server, the CMS continuously monitors the source server and displays data such as CPU usage, memory usage, and disk data increase in a certain period.

Users evaluate the system based on the given data. If an accurate evaluation is not possible, consult the relevant professionals.

1.1.1.53 What are the special notes for Linux OS?

You must have the root permission on the migration source.

The mount point to be migrated must be correctly written into the fstab file.

1.1.1.54 Will the UUID of the OS change?

The UUID of the OS changes. Applications that depend on the system UUID must be authorized again, such as Windows authorization and EDR authorization.

1.1.1.55 If the migration source (Windows OS) contains mostly small files and a large amount of data, is the migration faster to use other methods such as file sharing?

The CMS is much more efficient in handling a large number of small files. Although the actual migration speed of the CMS may be only slightly higher than that of other transfer methods such as file sharing, thanks to its excellent migration stability, the CMS can avoid many of the problems associated with migration interruptions, such as reconnection, traversal re-checking, and so on. This method improves migration success and security.

1.1.2 

1.1.2.1 What are the compatibility lists?

For more information, see the Server Migration Compatibility List.

1.1.2.2 Can the migration proceed when the boot of the migration source is in any non-standard location?

No.

The eSurfing Cloud system boot must be the first partition of the first disk, and the boot cannot be written to other locations. Otherwise, the system cannot be booted.

1.1.2.3 Can the migration proceed on the migration source using the shared bandwidth?

No.

The CMS supports only exclusive bandwidth for migration, instead of shared bandwidth. Otherwise, the network condition on the migration source may not be obtained.

1.1.2.4 Can the migration proceed on the migration source using the DNAT service?

No.

The CMS supports only exclusive bandwidth for migration, instead of the DNAT service. Otherwise, the network condition on the migration source may not be obtained.

1.1.2.5 Can the CMS migrate BMS to the cloud?

BMS migration is not supported.

1.1.2.6 What are the important disclaimers for the server migration service?

For more information, see Disclaimer.

1.1.2.7 Is there a limit on the number of migration sources and migration tasks?

Each user can activate a maximum of 1,000 migration sources.

Each user can create a maximum of 1,000 migration tasks.

Each user can execute 50 migration tasks concurrently.

Each migration source can be associated with only one migration task in an unfinished state at a time, including Ready, Running, Stopped, InError, and Expired.

1.1.2.8 Are there restrictions on migrating source binding?

Each migration source can only be bound to one migration target at a time, and the only migration task in an unfinished state is generated. A migration task whose migration status is Completed or Abnormal is not bound to the target server as the migration source.

1.1.2.9 Are there software, hardware, and license restrictions on the migration source?

Unauthorized application software, pirated software, clustered databases, U-Key hardware verification, and some hardware binding verification affect the use of the product.

1.1.2.10 In Windows Server Event Viewer, a message is displayed indicating that volume shadow copy of Volume x: is aborted because volume shadow copy storage failed to grow. What can I do?

Change the location where the volume shadow copy is created.

1. Open Resource Manager.

2. Select the drive letter of the original volume shadow copy and right-click and select Properties.

 

3. Click the Volume Shadow Copy tab, select the drive letter, and then click Settings.

 


4. Go to Storage Areas > This Volume to select the newly mounted disk.

 


5. Select No Limit in Maximum Value and click OK.

 

1.1.3 

1.1.3.1 What are the network requirements for a CMS migration?

The source and target servers must be able to access the platform.

The source server must be able to access the target server.

If the migration environment is on the public network, DDoS attacks may occur and thus memory overflow occurs in the PE system of the target server. Therefore, you must configure security group policies for the target server and allow ports 8000 (data) and 8001 (control) in the inbound direction of the target server.

You do not have to allow ports on the source server. However, we recommend that you check whether all ports on the source server are allowed in the outbound direction.

For more information, see Test Target Server.

1.1.3.2 How to Configure a Security Group

1. Go to the security group configuration page.

 

0. Expand security groups and Click Add Rules.

 

0. Configure port 8000 in the inbound direction of the target server.

 

0. Click Add Rules again and configure port 8001 in the inbound direction of the target server.

 

0. You can view the security group rules you created.

 

1.1.3.3 Why is the following error message displayed when binding to the target server: Error message xx: Source IP address (xx): Failed to communicate with the target server: Obtaining the deployment result timed out. Check whether the target server is a Linux x86_64PE system?

You must check whether the OS of the target server is correct;

You must check whether ports are allowed in the security group. For more information, see Test a Target Server.

1.1.3.4 What should I do if the migration or network is interrupted?

If migration is interrupted, you can view the reason for migration failure in the Alarm Center to help you start migration again.

If the migration stops due to network interruption, you must check the network condition. The CMS supports resumable transfer. The migration will resume automatically when the network resumes normal operation.

1.1.3.5 What should I do if the CMS displays that the migration Agent is offline?

This may be caused by the network instability on the migration source.

Solution: Restart the migration Agent on the source server: you can run the sudo movecloud restart -y command on the migration source to restart the migration Agent and continue with the migration task.

1.1.3.6 The repair has not been completed for a long time when CMS is auditing the repair. How can I determine whether the migration task is normal?

The auditing will take a long time due to factors such as the number of files and the number of large files to be migrated on the migration source. If this problem persists for a long time, you can perform the following steps for troubleshooting.

1. You can view the task tracking information to check whether the progress is being updated. If so, the auditing task is proceeding normally.

2. If there is no progress update for the auditing task, the migration task may get stuck. In this case, you can run the sudo movecloud restart -y command on the migration source to restart and resume the migration task to complete the auditing repair task.

1.1.3.7 How can I check whether the task is normal if the CMS has not completed incremental data migration for a long time?

The incremental migration speed may be affected by factors such as the number of files, the total number of files, and the number of large files for incremental migration on the migration source, or the incremental migration may get stuck due to the inaccessibility of hardware devices. If this problem persists for a long time, you can perform the following steps for troubleshooting.

1. You can check whether the Agent is the latest version, run the movecloud version command, and compare the result with the Agent version on the platform to check whether the client version is correct.

2. You can check whether the Agent is online. Ensure that the Agent is normally connected to the CMS console.

3. You can view the migration log on the source server (/usr/local/moveCloud/log/), in order to learn about the information of an incremental migration.

4. If none of the above methods work, you can try to stop the application and run the sudo movecloud restart -y command to restart and continue the migration task to ensure that the increment completes properly.

1.1.3.8 How do I know a migration is in progress?

Check that the migration is in progress in the following steps:

1. Log in to the CMS console in your region.

2. In the left-side navigation pane, click the Server Management tab.

3. Select a server and click Details. The Migration Details page is displayed.

4. Click the Migration Log tab and click Magnifying Glass several times.

· In a Linux OS, the page displays:

[INFO] xxxx.xx.xx xx:xx:xx [arcredisProxy.go:140][GOID:13] get task12.

This indicates that the migration is normal.

· In a Windows OS, the page displays:

[xxxx-xx-xx xxxx] [daily_logger] [info PublicFunc.cpp:6611] [thread 1260] 4.06654e+06b/S,1.82146%,3826.96s,d=1.82146%288724463.

The ongoing progress update indicates that the migration is normal.

1.1.3.9 What should I do if special migration modes such as dedicated access/VPN or Intranet VPC peering are used?

For issues regarding special network environments, you can submit a ticket for advanced technical consulting.

1.1.3.10 What should I do if the source server cannot access the Internet and an agent program is required for migration instead?

For issues regarding special network environments, you can submit a ticket for advanced technical consulting.

1.1.3.11 Can I release/modify the EIP during migration?

No. When the CMS migrates resources, the EIP maintains communication between the migration source, target server, and the platform. If you release or modify the EIP on the target source during migration or synchronization, migration or synchronization tasks fail.

You can release or modify the EIP on the target server only after the migration is complete.

1.1.3.12 What should I do if the command line prompts: sudo : wget: The command cannot be found when I download the CMS-Agent on a Linux-based source server?

The wget service is not installed on the source server.

Solution:

· Install wget with the command: yum -y install wget.

· If you download the file using other machines, import the file to the source server.

1.1.3.13 How long will a migration task take?

You can estimate the migration duration before migration starts using the following formula: Migration duration = Total data volume/Bandwidth size/8*1.25. For more information about duration estimation, see Evaluate Migration Duration and Test Transfer Speed.

1.1.3.14 How can I check the remaining time of the current migration task on the CMS?

You can view the information including the remaining time, in the following steps:

1. In the left-side navigation pane, click the Server Management tab.

2. In the server list, select the row where your desired server is located and click Start Migration or Details in the Operation column.

3. On the Task Details page, click the Task Tracking tab. Under this tab, you can view information such as migration status, total time, estimated completion time (current status), average speed, and real-time speed.

1.1.3.15 How are data such as migration speed shown on the CMS console calculated?

Terms and definitions:

Migration Metrics

Description

Total data volume

You can view the total used space of all partitions to be migrated using the disk management tool.

Amount of migrated data

Specifies the size of the migrated data, counting only the data of the used space in the partitions.

Elapsed time

Specifies the elapsed time after a migration starts.

Remaining Time

(Total data volume - the amount of migrated data)/Migration speed

Migration speed

The real-time speed is calculated based on the amount of data migrated within 5s. The migration speed is not the same as the transfer rate of the NIC, and may vary depending on file size, compression ratio, and network transmission loss.

1.1.3.16 How to speed up migration?

· Adjust the compression ratio.

· Tune the network.

The bandwidth for migration uses the minimum bandwidth among the egress bandwidth on the source server, ingress bandwidth on the target server, and the bandwidth limit configuration on the CMS console. You can increase the migration speed by increasing the minimum bandwidth.

1.1.3.17 Why is the migration speed sometimes fast and sometimes slow and largely different from the transmission rate of the NIC?

The real-time speed is calculated based on the amount of data migrated within 5s. The migration speed is not the same as the transfer rate of the NIC, and may vary depending on file size, compression ratio, and network transmission loss.

1.1.3.18 How to test the network connection using IPerf?

For more information, see Evaluate Migration Duration and Test Transfer Speed.

1.1.3.19 What determines the migration bandwidth?

The minimum bandwidth among the following three bandwidth specifications shall be used:

· Egress bandwidth on the migration source.

· Ingress bandwidth on the target server.

· Bandwidth limit on the CMS platform.

1.1.3.20 How do I know if a migration task gets stuck?

· Check whether the current speed displayed on the CMS (migration speed, auditing number) is normal.

· Check the migration log on the source server. If the log is not refreshed for an extended period of time, the task may be abnormal.

1.1.3.21 What is the cause of the large gap between the estimated migration time on the CMS platform and the actual migration completion time?

The estimated migration time is estimated according to the current time. The actual migration time is affected by many factors, such as the number of small files on the migration source, the number of changes to large files, the stability of the migration network, and too low CPU and memory specifications of the migration source for peak performance.

The estimated migration time of the CMS platform is for reference only. You can also refer to the estimated migration time in the FAQs in the Help Center. If you need a more accurate and rigorous migration time, perform the corresponding Migration Test.

1.1.3.22 Why is the migration speed sometimes much lower than the bandwidth size?

The reasons for this phenomenon are generally but not limited to the following:

· Too many large files

· Too many sparse files

· The hardware capabilities of the original system, such as CPU and memory, are limited

1.1.4 

1.1.4.1 How to install CMS-Agent?

For more information, see Install Agent on the Source Server.

1.1.4.2 What can I do if I fail to download CMS-Agent?

Reason: The network fails or the wget program is not installed on the source server.

Perform troubleshooting in the following steps:

· Check whether the source server can access the CMS. If not, check network failures.

· The wget program is not installed on the source server. Install wget and try again.

· The permission limit applies to the source server. Check whether the user has the download and installation permissions.

1.1.4.3 How to verify the version compatibility between the CMS-Agent and the platform?

The CMS-Agent automatically verifies version compatibility and displays a prompt when the program fails in boot verification.

After the CMS service is updated, if an announcement asks you to delete the previous Agent version and download the Agent again, uninstall your local Agent and download it from the source server.

Description

In this case, you must download the CMS-Agent again on the Migration Agent page, instead of using One-click Upgrade on the Server Management page.

1.1.4.4 No record exists in Server Management after the Agent on the migration source is reported.

Perform troubleshooting in the following steps:

· Check whether the AK/SK is correctly entered during installation.

· Check whether the startup program pop-up window displays "Started successfully", or whether "movecloud success" is displayed in the Linux shell.

· Check whether the platform version matches the Agent version.

1.1.4.5 What files need to be concerned about on the CMS?

· Log file.

For more information, see the following topic: How do I view migration logs on the CMS?

· Other files.

linux pe files:

mkinit.log (generated upon boot repair, /usr/moveCloud/)

diskLayout.log (generated upon partitioning, /usr/moveCloud/)

1.1.4.6 How do I view migration logs on the CMS?

Log file path on the Linux CMS:

· Directory of Linux Agent: /usr/local/moveCloud/log/

· Directory of Linux PE: /usr/moveCloud/log/

Log file path on the Window CMS:

· Default directory of Windows Agent: C:\Program Files (x86)\MoveCloud

· Default directory of Windows PE: X: Program Files \MacMigrationSer\

1.1.4.7 Why do I fail to start CMS-Agent?

Check the network connection: Check that the source server normally communicates with the platform.

For more information, see Test Target Server.

1.1.4.8 Why do I fail to start Windows Agent by double click?

Issue Description

After Windows Agent is installed, the CMS-Agent installation program does not respond when you double click it.

Problem Analysis

The file is locked in the security policy in System Settings. You must unlock the file.

Solutions

Right-click CMS-Agent-py*. to display properties, select Unlock, click OK, and run the program again.

1.1.4.9 What should I do when the message is displayed, indicating that "the json.dll file is missing and Agent startup fails", after CMS_Agent (Windows) is installed?

1. Check whether the CMS_Agent (Windows) program is unzipped. If not, unzip it and restart the program.

2. Check whether the json.dll file was deleted by mistake. If so, please download the program installation package on the platform again.

3. Check whether the firewall misidentifies the program as risky and kill it. If so, add CMS_Agent to the trustlist or disable the firewall and restart the program.

4. If the problem persists, we recommend that you download the CMS_Agent program from the platform, unzip it and start it again.

1.1.4.10 What should I do when the message is displayed, indicating that "The host has been bound by another user;Installation failed!" when you enter the AK/SK after Agent (Linux) is installed?

Cause: The device has been registered with another platform.

Solution:

· Delete the device task from its registered CMS service platform

· Log in to the migration source and run the command rm -rf /etc/.movecloud_uuid to delete it.

Note:

The rm action has certain risks. Identify the impacts of the rm action before proceeding.

 

1.1.4.11 What should I do if I cannot paste AK/SK after the Windows 2008 Agent starts?

You can use the paste command on the client software, such as crt or xshell, to paste the AK/SK.

1.1.4.12 [Why "[ERROR]xxx Permission denied" is displayed in the migration log?

This is usually because the current user has no permission to execute the file or folder:

· The user has insufficient permission on the file or folder.

· The current user is not the owner of the file or folder.

· The file or folder does not exist.

1.1.4.13 How do I restart the Agent?

If the migration source goes online, the CMS-Agent is not normally running on the migration source.

You must restore the migration source to online and create a migration task in the following steps:

For a Linux OS:

1. Check the service process: ps -ef |grep moveCloud or movecloud status.

2. Restart the process service: movecloud restart.

For a Windows OS:

3. View the service process: View the movecloudManage process in Task Manager.

4. Restart the process service: moveCloud.

1.1.4.14 What should I do when the message indicating that "[ERROR]No space left on device" is displayed?

Issue Description

After the CMS is normally started, the following message is displayed in the log:

ERROR: No space left on device

Problem Analysis

This error is reported due to insufficient storage space on the migration source.

The migration process consumes some space. For a Windows OS, we recommend that 10% of the total space be reserved.

For a Linux OS, pay attention to the usage of the source server. You do not have to reserve storage space.

Solutions

1. Log in to the ECS on the migration source and check the storage space usage.

2. If the available storage space is insufficient, you can delete unnecessary files or increase the storage space on the source server.

1.1.5 

1.1.5.1 What are the precautions for partitions on the CMS?

1. Maintain the corresponding relationship with the mount point of partitions on the migration source.

2. The eSurfing Cloud system boot must be the first partition of the first disk, and the boot cannot be written to other locations. Otherwise, the system cannot be booted.

3. Note: No error is allowed in the /etc/fstab file.

4. Check whether shared storage is mounted.

1.1.5.2 How to view Windows Server Event Manager?

Use the Win + R shortcut key to launch the RUN command window. Type "eventvwr.msc" in the command window and press Enter to open Event Viewer.

1.1.5.3 Is there a limit on the number and capacity of disks on the migration source?

The capacity for a single disk is not limited but the number of disks must be less than 24. If the number of disks is exceeded, reduce the number of disks on the source server or submit a ticket for technical consulting.

1.1.5.4 Why is the message displayed indicating that the space of the target server is smaller than that of the source server when I configure a task even when the target server has the same disk specification as the source server?

The method for space calculation of eSurfing Cloud is somewhat different from that of local and other cloud service providers. Users must identify the space size by themselves before proceeding with migration.

1.1.5.5 What is the custom partition adjustment range?

For common partitions and logical partitions, the partition size must be larger than the usage of the migration source.

1.1.5.6 What should I do if new data is generated on the migration source during migration?

The CMS supports incremental data migration. You only need to select incremental migration when you configure a task. The CMS will monitor incremental data and perform incremental data migration in the incremental migration phase after the full data migration is complete.

1.1.6 

1.1.6.1 What are the changes between the target server and the source server after migration?

When using the server migration service, you need to modify some parameters when configuring a migration task. The modification content of these parameters is strongly related to the operating system, corresponding files, and parameter settings. The parameters modified in the migration configuration may change with version iteration and system updates. The parameters listed in this table are for reference only. The server migration service reserves final interpretation.

Table 1 Parameters that are consistent on the target server and source server after migration (common to Windows and Linux)

Parameter

ECS after Migration

Remarks

OS type

The OS is the same as that of the ECS on the migration source.

The OS of the target ECS is overwritten by the OS of the source ECS.

IP

IP address of the target ECS

The Internet IP address changes after the migration. If the CIDR block of the target ECS in the VPC contains the source Intranet IP address, the Intranet IP address can be set to unchanged.

Username

The username is the same as that of the ECS on the migration source.


Password (Certificate)

The username, certificate, and password are the same as those of the ECS on the migration source.


Data

Data, including files, applications, and configurations, are the same as those on the migration source.


Table 2 Changed parameters and modified configuration items after a Windows ECS is migrated

Parameter/Configuration Item

ECS after Migration

Remarks

MAC address

MAC address of the target ECS

The MAC address is an inherent attribute of an NIC and has been determined when you create a target ECS.

DNS

May change (high probability) · The parameters in the DNS configuration file are the same as those on the migration source.· The DNS configuration of the target subnet affects the DNS resolution of the target server.

You can modify it on the target server after the migration is complete.

EIP

The bound EIP of the target server after the migration

-

Size of disks and partitions

The size of disks and partitions of the target ECS you select when configuring the target server.

If you choose to adjust the disk partition, the size of the disks and partitions after migration depends on the size set when you configure the target server.

Host SID

Use the SID of the target ECS.

 

For a Windows OS, SID is a hardware property. The SID is different from server to server and cannot be migrated. Therefore, if a source ECS is added to a domain, the SID will become invalid after being migrated to the target ECS. Therefore, you must add the SID again.

Registry and BCD boot options

Modify as needed

To adapt to eSurfing Cloud, the server migration service will modify the registry and boot options as needed.

Dynamic partition

Reset the dynamic partition

If the Windows ECS is booted from BIOS, the system reconfigures the dynamic partition.

Driver file directory

Copy the driver file on the source server to the driver directory on the target server.

-

Table 3 Changed parameters and modified configuration items after a Linux ECS is migrated

Parameter/Configuration Item

ECS after Migration

Remarks

MAC address

MAC address of the target ECS

The MAC address is an inherent attribute of an NIC and has been determined when you create a target ECS.

DNS

May change (high probability) · The parameters in the DNS configuration file are the same as those on the migration source.· The DNS configuration of the target subnet affects the DNS resolution of the target server.

You can modify it on the target server after the migration is complete.

EIP

The bound EIP of the target server after the migration

-

Size of disks and partitions

The size of disks and partitions of the target ECS you select when configuring the target server.

If you choose to adjust the disk partition, the size of the disks and partitions after migration depends on the size set when you configure the target server.

Disk name

Depends on the virtualization type of the target server.

Generally, applications are not affected.

UUID and PARTUUID of disk and partition

The UUID and PARTUUID are regenerated on the target server.

Only for file-level migration in a Linux OS.

Grub configuration file

The grub boot configuration file is modified based on the UUID of the boot disk or boot partition on the target server.

· grub must be installed on the ECS in BIOS boot mode, and the grub configuration file in the /boot/grub directory will be modified. · For elastic cloud servers in UEFI boot mode, the UUID in the grub configuration file in the /boot/efi/ and /boot/grub directory will be modified.

Booted initrd or initramfs

Injecting relevant drives

Injecting drives ensures that the target ECS can start normally in eSurfing Cloud.

xorg.conf configuration file for X11

The target server will update the /etc/X11/xorg.conf configuration file.

This file affects the graphical interface and display-related parameters. The original file is backed up as /etc/X11/xorg.conf.bak.

SElinux security configuration

The /.autorelabel file is generated for the purpose of re-labeling.

Only for Redhat, CentOS, and Oracle systems.

Motd

The /etc/motd file is changed to null.

By default, the startup logo is not set.

fstab boot options

fstab is regenerated based on the UUID of the new target server and mount condition.

The old /etc/fstab boot record on the target server is annotated.

Cloud-init

Cloud-init is disabled on the target server.

The /etc/cloud-/cloud.cfg file will be deleted.

NIC configuration

Some network-related configuration files are deleted from the /etc/udev/rules.d/ directory, and DHCP is backed up and modified based on different systems.

The NIC configuration file is modified. For example, the ifcfg-eth* file is modified for Redhat, CentOS, SUSE, and EulerOS systems. The yaml file is modified for Debian/Ubuntu systems.

1.1.6.2 Will the password of the target ECS change after the migration?

After the migration is complete, the password of the target ECS is the same as that of the source ECS.

1.1.6.3 How do I configure the yum source after the migration is complete?

Do not modify the configuration on the source server.

1.1.6.4 Why is the drive letter of the target server different from that of the migration source after the Windows Server is migrated?

This is because of the Windows mechanism. The drive letters on the target server are continuous, that is, C:, D:, and E:. After restarting the target server, you can manually change the drive letters in Disk Management based on the drive letters on the migration source to prevent the effect on the application system.

1.1.6.5 How to adjust various partitions?

Before the migration, if the space of partitions on the target server is larger than that on the source server, the partition size is automatically changed after the target server is restored.

After the migration is complete, you can increase the disk capacity of the ECS:

Steps to Increase Disk Space in a Windows OS

1. Open the Run command from the Start menu.

2. Type "diskmgmt.msc" and press Enter. The Disk Management page is displayed.

3. Right-click the drive letter that you need to adjust and choose Extend Volume.

4. In the dialog box that appears, click Next.

5. Increase the unallocated space of this disk as needed, and then click Next.

6. In the dialog box that appears, click Finish.

7. If the space expansion operation is complete and the disk space information is normal, the space expansion is complete.

Steps to Increase Disk Space in a Linux OS

The following example only applies to most Linux versions. Otherwise, increase the space by following the instructions provided in the respective Linux manual.

1. Check the disk status (lsblk, fdisk -l, pvdisplay). lsblk

2. Create a physical volume (pvcreate). pvcreate /dev/sdb

3. Extend a disk to a volume group (vgextend). vgextend centos /dev/sdb

4. Extend a logical partition (lvextend). You can expand the capacity to a partition based on your needs. This section uses centos-root as an example. lvextend -l+100%FREE /dev/mapper/centos-root

5. Note: 100% indicates that all disk space is expanded for the specified partition. You can also determine the adjustment proportion as required.

6. Make the extension effective (xfs_growfs). xfs_growfs /dev/mapper/centos-root

7. View details (df -H). df -H

1.1.6.6 The MySQL database cannot be started after migration

Issue Description

After the migration, the MySQL database fails to start normally or exits after a short startup.

Problem Analysis

This is because the applications on the source MySQL database do not stop and the related files on the target database do not match.

Solutions

Stop all applications on the source MySQL database at an appropriate time and synchronize the data again.

1.1.6.7 Incorrect SELinux configuration results in failures to access the system

Issue Description

After the migration is successful, the system gets stuck during startup and cannot be accessed. "SELinux targeted" is displayed on the page.

Problem Analysis

This may be caused byincorrect SELinux configuration. Disable SELinux and try again.

Solutions

The following operations apply to some subsystem versions and do not apply to all problems. However, you can troubleshoot problems based on the following ideas:

1. Find a temporary ECS that can access the Internet in the same availability zone as the target ECS, and mount the system disk of the target ECS to the temporary ECS.

2. Mount the partition related to the system disk of the target server to the temporary ECS.

3. On the temporary ECS, locate the SELinux configuration file of the system disk of the target server and set SELinux=Disabled.

Note:

Do not modify the SELinux configuration file on the temporary ECS.

0. Mount the system disk and related partition on the temporary ECS back to the target ECS and restart the system.

1.1.6.8 Will the CMS automatically install the eSurfing Cloud plug-ins after the cloud migration?

The following three types of plug-ins are installed:

· ctcm-agent: ECS monitoring content.

· cloudinit: Executed at cloud system initialization and initial startup.

· qemu-guest-agent: Various virtualization functions.

1.1.6.9 After the Windows system is migrated, a blue screen occurs when I start or log in to the system, and then the system restarts

Such problems can be eliminated using the following methods:

1. Check whether the migration source is faulty.

2. Check whether the installed tools invoke the underlying API, affecting the migration source system.

1.1.6.10 After the first full data migration is complete, if I change the password of the source ECS, will the new password of the migration source be synchronized when I execute the synchronization process?

The first full data migration of the server migration service will migrate the password of the ECS on the migration source. If you change the password of the source ECS after the full data migration is complete, the Windows OS and Linux OS can execute the synchronization process, but the new password will not be synchronized to the target ECS. After the migration is complete, if you need to reset the password of the target server, reset the ECS password on the console.

Description

The password of the ECS on the migration source you changed takes effect only after the ECS is restarted.

 

1.1.7 

1.1.7.1 How to migrate resources?

For server migration, see the steps in the User Guide.

1.1.7.2 What are the basic steps for using the CMS?

Basic steps for using the CMS for cloud migration: migration survey, migration evaluation, downloading and installing the CMS-Agent, activating the target server, binding the target server, configuring migration tasks, full data migration, cyclic increment, stopping increment, business switchover, and business verification.

For more information on server migration, see the steps in the User Guide.

1.1.7.3 How do I check the system after the migration?

General checklist:

1. Check whether you can log in to the ECS with the password of the migration source.

2. Check whether the server name configuration and network service are normal.

3. Check whether other system application services are normal.

For a Windows OS, you must check the following:

1. Check whether the data in the system disk is complete.

2. If a data disk is missing, go to Disk Management to check whether the drive letter is missing.

For a Linux OS, you must check the following:

1. Check whether the data in the system disk is complete.

2. View the mounting status of each mount point.

1.1.7.4 How to create a migration task again after the migration is complete?

Bind the migration source to a new target server and reconfigure the task.

1.1.7.5 What should I do when the target server cannot be found or bound after a migration task is created?

· The Binding page provides no check mode to detect the target server:

Under the current account or enterprise account, you must check whether the region you selected for the CMS service is consistent with that of the target server. If not, the platform cannot detect the target server.

· Unable to bind the check mode:

1. Check whether the system of the migration source matches that of the target server. If not, binding fails.

2. Check whether ports are allowed in the security group of the target server and whether ports are allowed in the outbound direction of the source server.

3. For more information on binding a target server and port settings in the security group, see Bind Target Server.

1.1.7.6 How do I search for a migration source?

Search for a migration source in the following steps:

1. Log in to the CMS console in your region.

2. In the left-side navigation pane, click the Server Management tab.

3. On the Server Management page, click the search box.

4. Enter the query condition and click Enter.

Description

The search items include the alias, EIP, and private IP address of the migration source. All search terms support fuzzy search.

 

                  

1.1.7.7 How to import migration sources in batches?

Import migration sources in batches in the following steps:

1. Log in to the CMS console in your region.

2. In the left-side navigation pane, click the Server Management tab.

3. Click Download Import Template to download the template.

4. Enter the template content.

5. Click Import Excel to import migration sources.

6. Click Import Log to view the import result.

Description

Enter the alias and IP address of the source server, and target server ID in the EXCEL template. Click the target server to view the target server ID in details. For more information, see Bulk Import and View Migration Sources.

 

 

                  

1.1.7.8 Why do I fail to delete migration sources?

If a migration source is online, you cannot delete it on the Server Management page.

1.1.7.9 "delete snapshot xx error!" appears in the migration log What should I do?

QGA affects the VSS service. You must close and disable QEMU Guest Agent VSS Provider (QGA) for migration sources.

Procedure:

1. Use the Win + R shortcut key to launch the RUN command window and type "services.msc".

2. Locate the service and close and disable it.

1.1.7.10 An error message is displayed when the VSS service is migrated. How can I perform troubleshooting?

You can use the Windows Server Event Viewer to locate the fault.

Procedure:

1. Open Control Panel, click View Event Log under System and Security.

2. Open the collapsed Windows logs directory to view error items.

1.1.7.11 What should I do if "Partitioning failed" is reported on the platform?

The "Partitioning failed" message is reported when a partitioning task is issued on the platform. This is because partitioning fails on the target server.

You must check whether the source server normally communicates with the target server.

1.1.7.12 How to limit CPU and bandwidth during migration?

On the Server Management page, in the row that contains the target migration source, set CPU Limit and Bandwidth Limit for migration tasks from the Operation drop-down list.

 

1.1.7.13 What should I do if the target ECS is deleted by mistake during migration?

A migration task is automatically canceled when you delete the target server by mistake.

You must bind the target server again and restart the migration task.

1.1.7.14 What should I do if the error message "error: file "/boot/grub/i386-pc/xxx.mod" not found" is displayed and I fail to start the target server upon a boot repair?

1. Confirm the boot mode

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

2. Check whether the i386-pc folder exists in the /usr/lib/grub/ directory and whether the folder is empty.

ls /usr/lib/grub

ls /usr/lib/grub/i386-pc

0. Find a temporary ECS with the same operating system and system version as the source server.

scp -r /usr/lib/grub/i386-pc username@xx.xx.xx.xx:/usr/lib/grub/

1.1.7.15 What should I do if the following error message is displayed when I start the target server upon a boot repair: error: file "/initrd.img" not found, error: file "/vmlinuz" not found?

You can eliminate problems in the following steps:

The following example only applies to most versions. Otherwise, follow the instructions provided in the respective manual.

error: file “/vmlinuz” not found

1. Use a bootable repair medium to boot the system and mount the /boot partition of the system disk.

2. Extract the vmlinuz kernel file from the installation medium or system backup and copy it to the /boot partition.

3. Update the boot configuration (grub.cfg) to point the linux line in the menuentry block to the vmlinuz kernel file.

4. Restart the system and select the updated menu item in the boot menu to boot the system.

error: file “/initrd.img” not found

1. Mount the /boot partition and get the initrd.img file.

2. Copy the initrd.img file to the /boot partition.

3. Update grub.cfg, locate the initrd line, and point it to the new file.

4. Reboot the system and start the updated menu item.

1.1.7.16 What should I do if a message indicating that "Partitioning failed. Please ensure the network connectivity between the source and target servers and exit the remote console of the target server, and try partitioning again" when the CMS assigns a task?

When you encounter a network exception when configuring CMS tasks, you can use the connectivity test function on the configuration page to ensure the connectivity between the migration source and the platform, and between the migration source and the target server. If the network connection is normal, you can check whether the console connection interface of the target server is in use. If so, exit the console and assign a task and create a partition.

1.1.7.17 What should I do if no error message is reported when a migration task is complete on a Linux OS but data is missing on the target server?

Check whether the mount point to be migrated is correctly written into the fstab (path: /etc/fstab) on the source server and whether you have the root permission to start the Agent.

1.1.7.18 What should I do if I cannot create a migration task because the platform displays a message indicating that the migration source is offline?

If the migration source goes online, the CMS-Agent is not normally running on the migration source.

You must restore the migration source to online and create a migration task in the following steps:

For a Linux OS:

1. Check the service process: ps -ef |grep moveCloud or movecloud status.

2. Restart the process service: movecloud restart.

For a Windows OS:

1. View the service process: View the movecloudManage process in Task Manager.

2. Restart the process service: moveCloud.

1.1.7.19 Can I create a concurrent migration task for the migration source if I need to initiate the migration again?

No.

If a migration error occurs or you need to initiate the migration again, you must delete the original migration task and create a migration task.

1.1.7.20 What should I do if a message indicating that the target server is being bound even when I fail to bind the target server?

1. Log in to the target server remotely.

2. ps | grep move: Check the current program process. (The program process and binding process exist.)

3. kill -9 xxx: Kill all processes.

4. In the root directory: nohup ./moveDaemon > /moveDaemon.log 2>1 & "Restart the program".

5. Try reconnecting again.

1.1.7.21 Why does an error occur when obtaining the IP address when I use the CMS?

The IP address cannot be obtained and is displayed abnormally when non-exclusive bandwidth is used.

The shared bandwidth and DNAT service do not support the CMS service. The CMS service works only with exclusive bandwidth.

1.1.7.22 Can I modify and reset the password on the eSurfing Cloud page after the device is migrated to the cloud?

Yes.

After the migration is complete, the eSurfing Cloud reset password package will be installed in the system. You can modify and reset the device password on the eSurfing Cloud page.

1.1.7.23 Will the password be reset when I use eSurfing Cloud to create a private PE image?

Yes.

You must enter a password when you create a private PE image using eSurfing Cloud. You only need to enter a password that meets the password complexity requirement twice and the two passwords must match. The password will be reset when you use the PE program.

1.1.7.24 Will the password be reset when I create a private image using an ECS after the migration?

No.

When you need to create a private image for the migrated system on eSurfing Cloud, you must enter a password that meets the password complexity requirement twice and the two passwords must match, but the system password will not be reset.

1.1.7.25 What should I do when I cannot download the client properly?

If you fail to download the client, this is generally because your browser is not compatible with the plug-in.

You can change your browser and access the platform again to check whether the problem is eliminated.

1.1.7.26 What should I do when I fail to deploy a target server?

When you deploy a target server, problems such as communication error, deployment failure, and timeout obtaining the deployment result may cause deployment failures.

You must to follow the instructions to check whether the target server communicates normally with the platform, whether the PE program is started normally, and whether the IP address of the PE program is lost.

1.1.7.27 What should I do when the "Getting feedback times out. Please check network connection" message is displayed on the platform?

When the "Getting feedback times out. Please check network connection" message is displayed on the platform, this is because the platform has not received the feedback from the source server.

You must check whether the source server normally communicates with the platform and whether the Agent program on the source server is running properly.

1.1.7.28 What should I do when the "Failed to establish communication" message is displayed during communication test?

The "Failed to establish communication" message is displayed when you test the communication between the source and target servers.

You must check whether the Agent and PE programs run properly and whether the source server normally communicates with the platform.

1.1.7.29 How to specify file directories that are not migrated or synchronized in file-level migration in a Linux OS?

The CMS is used for file-level migration. For more information, see File and Directory Filtering.

1.1.7.30 What are the options for filtering files on the migration source in CMS filtering rules?

You can set filtering rules to filter by file, directory, regular, and wildcard. At the same time, by combining filtering rules, you can filter files more flexibly and accurately.

1.1.7.31 How to add filtering rules if I select File as filter type when configuring filtering rules for the CMS?

1. Specify the Filter Path precisely to the corresponding file level.

2. The File radio button is automatically selected as the filter type.

3. Click OK to successfully add the file filtering rule.

Note:

This rule will filter this file. Please proceed with caution.

 

 

                  

1.1.7.32 How to add filtering rules if I select Directory as filter type when configuring filtering rules for the CMS?

1. Specify the Filter Path precisely to the corresponding directory level.

2. The Directory radio button is automatically selected as the filter type.

3. In the retained items configuration, select the files, directories, and directory trees in the retained directory.

4. Click OK to finish adding the directory filtering rule.

Note:

By default, this rule filters all files and directories in the directory except retained items. Please proceed with caution.

 

                  

1.1.7.33 How to add filtering rules if I select Regular as filter type when configuring filtering rules for the CMS?

1. Specify the Filter Path precisely to the corresponding directory level.

2. Manually select Regular as the filter type.

3. In the recursion option, select whether to apply repeated calls to the rule to subdirectories in this directory.

4. Click Add to add regular rules. Multiple expressions can be added as required.

5. Click OK to finish adding the regular filtering rule.

Note:

By default, this rule filters all files and directories in the directory matching wildcard expressions. Please proceed with caution.

 

                  

1.1.7.34 In the CMS, users can stop the incremental migration detection. Can I directly stop the incremental migration detection and stop applications as prompted?

You cannot stop incremental migration detection directly.

In the CMS, users can stop incremental migration detection, but this function is only effective in most scenarios. To ensure data consistency, we recommend that you consult the application service provider and stop the corresponding applications before stopping the incremental migration detection.

1.1.7.35 What should I do if the CMS migration gets stuck in the preparation phase for an extended period of time?

1. Check whether programs are running properly. You can check whether an error is reported in the log on the migration source.

2. Check whether special shared storage exists on the migration source. Basic filtering rules are configured on the CMS. If the special shared storage are not applicable for some filtering rules, you can submit a ticket to extend the scope of applications.

3. In an emergency, you can manually filter the directories, drive letters, and mount points related to the special shared storage to ensure smooth migration.

4. Migration sources involve large amount of data and require sufficient time and resources to handle this. Therefore, do not close tasks before checking that any error exists. Otherwise, the migration process may be affected.

1.1.7.36 In the CMS, users can set the compression ratio. How to use this feature and what impact does it have on the migration source?

You can set the compression ratio on the CMS. The minimum compression ratio is 0 and the maximum compression ratio is 9. The default value is recommended. In general, the higher the compression ratio, the smaller the amount of transmitted data, the shorter the migration time. A higher compression ratio also increases the CPU usage of the source server. Therefore, you must to make a trade-off when setting the compression ratio.

Test the compression ratio before use. The following shows an example of the migration speed and CPU usage on the test machine when different compression ratios are set.

For 100M 3G data servers with 2C4G, when the compression ratio is set to 0, the migration process takes 3 minutes and 40 seconds with CPU utilization up to 50%. For the same data server, when the compression ratio is set to 9, the migration process takes 2 minutes and 50 seconds with CPU utilization up to 99%.

1.1.7.37 What is the cause of the pop-up message indicating that "Please stop corresponding applications on the source server to ensure data synchronization" when I stop incremental migration detection in the migration tracking phase?

The pop-up window is intended to remind you of the application detection function on the migration source. This is generally because applications on the migration source are not completely stopped. To ensure data consistency between the migration source and the target server, we recommend that you click "Click to View Applications to Close" in the pop-up window and check the applications as prompted.

1.1.7.38 What applications are detected by the incremental migration detection function?

The stop incremental migration detection function is used to detect whether Oracle, MySQL, MariaDB, SQL Server, Redis, and Docker applications are running on the migration source. If these applications exist, the CMS console displays a prompt.

1.1.7.39 What shall I do if a message is displayed indicating that the boot repair fails when the CMS performs boot repair and "no space left on drive" is reported in the log?

First, you must check that the source server has enough space for migration. For a Linux OS, reserve at least 5% of the storage space. For a Windows OS, reserve at least 10% of the storage space. If the source server does not have enough space, you must optimize it before migration starts.

If the source server has sufficient disk space, you must check whether the target server has the same disk space as the source server. If the target server has insufficient disk space, you must increase the capacity.

1.1.7.40 What shall I do if the CMS can be bound properly, but when a migration task is delivered, the message "Failed to establish communication. Please check the network connectivity between the migration source and target server" is displayed?

The CMS platform uses TCP port 8001 to send the installer to the target server and the task configuration command is sent from the source server to the target server using TCP port 8000.

That is, the target server is bound properly but task delivery fails. Check whether the TCP port 8000 on the target server is allowed and is properly connected to the target server.

1.1.7.41 What should I do if the system displays "Failed to prepare the task. Please contact the administrator." when a migration task in a Windows OS is being configured on the CMS console?

Check whether QEMU Guest Agent exits. Select Disable as Boot Type and change Service Status to Stopped.

1. Use the Win + R shortcut key to launch the RUN command window and type "services.msc".

2. Check whether QEMU Guest Agent exists in the list.

3. If so, right-click and select Properties.

4. Change Boot Type to Disable and Service Status to Stopped.

5. Click Apply to save your changes.

If the problem persists, please submit a ticket and consult the relevant technical engineer.

1.1.7.42 Do I still need to click Start Auditing for data auditing upon completion if incremental data migration is not enabled?

No matter whether the increment is enabled or not, you only need to ensure that the migration process is strictly standardized instead of manual data auditing. The data auditing and comparison is time consuming when the data volume is large.

The CMS ensures data consistency based a specific algorithm during the migration process, and the data auditing function mainly acts as a backup solution for avoiding possible data inconsistencies if abnormal operations are involved.

It should be noted that if the increment is disabled, you must stop the incremental migration in advance before full data migration starts, that is, stopping applications to ensure data consistency.

1.1.7.43 What should I do if "Task does not exist" is reported?

If the message "Task does not exist" is reported when you deliver a migration task, this is because the previous migration task exits abnormally.

You must cancel the migration task and restart the migration.

1.1.7.44 What are the precautions for partitioning in a Windows OS?

Pay attention to the following three issues when partitioning in a Windows OS:

1. The target server must be allocated a system disk. The system disk must be migrated during migration, and the system disk on the source server must be migrated to the system disk on the target server. If the system partition of the target server is not on the first disk, it may not start properly after the migration.

2. The size of the destination drive letter cannot be smaller than that of the corresponding migration drive letter in a Windows OS.

3. A Windows system does not support dynamic disk migration.

1.1.7.45 What should I do if "Partitioning failed" is reported on the platform?

The "Partitioning failed" message is reported when a partitioning task is issued on the platform. This is because partitioning fails on the target server.

You must check whether the source server normally communicates with the target server.

1.1.7.46 What should I do if I fail to go to the partitioning page in a Windows OS?

If you fail to go to the partitioning page, this is because the basic disk information of the target server is not reported, and the migration program on the target server is running abnormally.

You must check whether the migration program on the target server is running properly and wait until the target server reports the required information to the platform.

1.1.7.47 What should I do if "Partitioning failed" is reported when partitioning in a Linux OS?

When you use the CMS to deliver Linux migration partition tasks, the "Partitioning failed" message is reported.

You must restart the target server. If the problem persists, reinstall the target server system.

1.1.7.48 What should I do if the target server has no IP address?

If the target host server does not have a DHCP environment, you must manually configure the IP address.

1.1.7.49 What should I do if "The task already exists" is reported?

After you click Start Migration, "The task already exists" is reported on the platform. A migration task may have ended unexpectedly.

You must reconfigure the migration task.

1.1.7.50 What should I do if the CMS-Agent (on a Windows OS) pop-up window displays that the service is running, but the program icon is not displayed in the background task tray?

This is because the Windows operating system adopts a mechanism called "single instance". When the same user logs in multiple windows, only the background tray program of the current active window is displayed. You can view the background tray program of other windows under the same user in Task Manager in the following steps:

1. Open Task Manager. You can open it in your window or by using the shortcut key "Ctrl+Alt+Del".

2. Click the Details tab.

3. Click the header in the Process column to sort it alphabetically.

4. Scroll to a similar application and click its line to select it.

5. Click Select Processes for the Same User under the Task Manager.

6. In the pop-up window, select the other windows and the processes of the background tray programs you need to view.

7. Click OK to display the selected processes and applications.

Note:

If you currently do not have the administrator rights, you may not be able to select processes for the same user. Similarly, if a user does not run multiple application instances or the background tray programs at a time, the programs and icons for the remaining instances may not be displayed in the Task Manager.

 

                  

1.1.7.51 What should I do if "Start moveCloud fail:redis:nil" is reported when the CMS-Agent(linux) starts?

This error may be caused by a version inconsistency between the CMS-Agent and the Redis on the platform. The solution is to re-download the CMS-Agent on the platform and install it, and then restart the CMS-Agent. If the problem persists, submit a ticket and consult the technical support.

1.1.7.52 What should I do if "start moveCloud fail" is reported when the Linux Agent starts.

This error is caused by abnormal package configuration file.

You can download the CMS-Agent installation package from the platform to eliminate the problem.

1.1.7.53 What should I do if "Boot failure(Failed to install GRUB)" is reported when I execute a migration task in a Linux OS?

This message means that an exception has been reported during boot repair;

You must log in to the target server to view the log (cat /usr/moveCloud/mkinit.log), search by ERROR or does not. In most cases, you may get no result.

If synchronization failed because you make incorrect configuration on the migration source, manually change sda in /boot/grub/device.map to vda and execute the migration task again. If ERROR occurs, consult the technical support.

1.1.7.54 What should I do if a migration program fails to start in a Windows OS?

When you double-click moveCloud.exe, the message "Failed to load configuration file" is reported. This is because the CMS-Agent cfg.ini file is missing.

You must re-download the CMS-Agent installation package from the platform.

1.1.7.55 What should I do if a migration program fails to get the Redis configuration in a Windows OS?

After you click Start Service, “Fails to get redis configuration“ is reported. In this case, you must check the network connectivity between the source server and the platform.

If the network connection is normal, re-download the CMS-Agent installation package from the platform.

1.1.7.56 What should I do if a migration program fails to connect to Redis in a Windows OS?

After you click Start Service, the "Failed to connect to Redis" pop-up window is displayed. This is because the migration source has a different network from that of the platform. You must check the network connectivity between the migration source and the platform.

1.1.7.57 What should I do if "Update program is missing" is reported when you click Start Server in a Windows OS?

When you click Start Service, the "Automatic update program is missing" pop-up window is displayed. This is because the Movemage.exe program is missing.

You must re-download the CMS-Agent installation package from the platform.

1.1.7.58 What should I do if "Update program exits unexpectedly" is reported when you click Start Server in a Windows OS?

When you click Start Service, the "Update program exits unexpectedly" pop-up window is displayed. This is because the moveManage.exe program exits unexpectedly during updating.

You must restart the start service.


nxB8J10SCmlj