This section describes the MgC constraints about region availability, server migration, cross-AZ migration, and storage migration.
Region Availability
MgC is available in the EU-Dublin region. While MgC is a region-level service, it offers global capabilities, allowing you to migrate to any region on the cloud. For information security purposes, all collected data and task records are stored in the region where MgC is available.
Server Migration
Table 1 lists the constraints on server migration using MgC.
Table 1 Constraints on server migration | Item | Constraint |
| Server migration workflows | - Each server can be migrated by only one workflow.
- Server migration workflows cannot migrate servers that boot using UEFI and have no targets associated. To migrate such servers using a workflow, associate them with existing UEFI servers on Huawei Cloud in advance. You can also use the Server Migration Service (SMS) to migrate such servers.
- SMS constraints also apply to server migration workflows.
- To migrate a server again, you need to stop the workflow, stop the SMS-Agent process on the server, delete the server record from the SMS console, and create a new workflow.
|
| Resource assessment and recommendations | - Target servers must have disks as least as large as source servers.
- Target servers must use the same type of OS as source servers.
- There must be sufficient quotas for recommended disk types in the target region.
|
| Migration prerequisite | All source servers have been assessed or associated with target servers. |
| Precautions during migration | After a migration workflow is created, the source servers must not be stopped or restarted, and disks on the source servers must not be changed. Otherwise, the migration will fail. |
| Source server settings | Any firewall or antivirus software must be stopped and WinRM must be started on Windows source servers. You can run winrm quickconfig check the WinRM settings. |
| Network connectivity | Source servers must be able to access Linux target servers over port 22 and Windows source servers over ports 22, 8899, and 8900. |
| MgC Agent server | - You are advised to prepare a Windows server for installing the MgC Agent in the source environment. The Windows server must be able to access the Internet.
- The server must have at least 4 vCPUs and 8 GB of memory.
- The server must use PowerShell later than 3.0. You can run the $host command in the PowerShell command window to check the version.
|
Cross-AZ Server Migration
Table 2 lists the constraints on cross-AZ server migration using MgC.
Table 2 Constraints on cross-AZ migration | Item | Constraint |
| Source server quantity | - A maximum of 30 servers can be migrated at a time using the automated process.
- A maximum of 100 servers can be migrated at a time using the manual process.
- Given the same set of environmental conditions, the more source servers there are being migrated, the slower the migration speed.
|
| Source server disks | - Servers whose system disk is larger than 1 TB cannot be migrated.
- You are not advised to migrate servers whose disk capacity exceeds 4 TB.
|
| Source server status | Frozen source servers in the retention period cannot be migrated. |
| Target servers | - Migrating to existing target servers is not supported.
- Target servers created by MgC are billed on a pay-per-use basis. You can manually change their billing mode from pay-per-use to yearly/monthly after the migration is complete.
|
| Shared file systems | MgC cannot migrate files from shared file systems such as NFS or CIFS, or from NAS devices. |
| Applications bound to hardware | MgC cannot migrate OSs that contain applications bound to hardware. |
| Servers added to domains | After migrating servers added to a domain, you need to add them to the domain again. |
| Encrypted files | MgC cannot migrate OSs that contain protected folders or encrypted volumes. |
| External storage of servers | MgC cannot migrate data from the external storage attached to a source server. |
| Server passwords | |
Storage Migration
Table 3 and Table 4 list the constraints on storage migration using MgC.
Table 3 General constraints on storage migration | Item | Constraint |
| Objects with multiple versions | By default, only the latest version of objects in source buckets is migrated. |
| Storage class of target buckets | The storage class of target buckets can only be Standard or Infrequent Access. You can change the storage class of target buckets after the migration is complete. |
| Migration object | - Object names cannot contain special characters.
- A single object cannot be larger than 4.76837158203125 TB (500 MB × 10,000). Otherwise, the migration may fail.
|
| Migration network | Migrations are supported over public networks, private networks, and private lines. |
| Symbolic links | - Symbolic links cannot be used for specifying migration paths which define the migration scope. If the migration path you specify is pointed to by a symbolic link, you need to:
- Enter the actual path when specifying the migration path.
- After the migration is complete, manually create a symbolic link to the path at the target.
- For migration from NAS_SMB or migration from NAS_NFS to OBS, symbolic links cannot be migrated.
- For migration from NAS_NFS to NAS_NFS, symbolic links can be migrated by enabling metadata migration. Otherwise, these files will be skipped during the migration.
- For migration from Alibaba Cloud OSS to NAS_NFS, symbolic links can be migrated by enabling metadata migration. Otherwise, the symbolic links will lose their link functionality and become regular files after the migration.
NOTICE: If the objects that symbolic links point to are not completely migrated to the target, these symbolic link files may fail the verification. As a result, the task will be in a failed status. In this case, wait until the involved objects are completely migrated to the target, and try the task again. |
| Hard links | For migration from NAS_NFS to NAS_NFS, hard links can be migrated by enabling metadata migration. Otherwise, these files will be skipped during the migration. |
| Migration scope | You can migrate a single bucket or multiple buckets in batches. |
| Metadata migration | - Only Chinese characters, English characters, digits, and hyphens (-) can be migrated. Other characters cannot be migrated.
- Chinese characters are URL encoded during the migration.
CAUTION: Chinese punctuation marks cannot be URL encoded during the migration. If metadata contains Chinese punctuation marks, the metadata and the corresponding object will fail to be migrated. - English characters, digits, and hyphens (-) are directly migrated without being encoded.
- For heterogeneous migrations, metadata cannot be migrated.
|
| Archived data | To migrate archived data from object storage, you must restore it first. You need to: - Ensure the restoration is complete before creating migration workflows.
- Configure a validity period for restored data based on the total amount of data to be migrated. This helps prevent migration failures because restored data becomes archived again during the migration.
- Pay your source cloud vendor for restoring archived data. To learn about the pricing details, contact your source cloud vendor.
|
| Concurrent subtasks | You can define the number of concurrent subtasks based on the number of online migration nodes. There cannot be more than 10 concurrent subtasks for each online migration node. For example, if there are 2 online migration nodes, the maximum number of subtasks can be 20 or any number below. |
| Object list files | These files must be stored in the same region as the target bucket. - These files must be in .txt format, and their metadata Content-Type must be text/plain. The directory where these files are stored cannot contain any other files or folders except for .txt files.
- A single file can contain a maximum of 100,000 rows.
- A single file cannot exceed 300 MB.
- A maximum of 10,000 list files can be stored in the folder.
- The files must be in UTF-8 without BOM.
- The length of each line in a file cannot exceed 65,535 characters, or the migration will fail.
- The Content-Encoding metadata of the files must be left empty, or the migration will fail.
- In the files, a tab character (\t) must be used to separate the URL and new file name in each line. The format is [URL][Tab character][New file name]. Only the Chinese and special characters in the file names must be URL encoded.
- Spaces are not allowed in each line in a file. Spaces may cause migration failures because they may be mistakenly identified as object names.
|
Table 4 Constraints on file system migration | Scenario | Constraint |
| Migration source: SMB systems | - File systems where a single directory contains more than 5 million files cannot be migrated.
- Resumable transfer is not supported.
- Symbolic links cannot be migrated.
|
| Migration source: NAS file systems | - The following types of files can be migrated: regular files, directories, symbolic link files, and hard link files.
CAUTION: If the file handle of a source file is occupied or the source file is deleted, the migration of the file will fail. - Special files such as character device files, block device files, sockets, and pipe files cannot be migrated.
- The metadata of symbolic link files cannot be migrated.
|
