Help Center/ Migration Center/ Service Overview/ Notes and Constraints
Updated on 2024-10-21 GMT+08:00
View PDF
Share

Notes and Constraints

This section describes the MgC constraints about region availability, server migration, cross-AZ migration, and storage migration.

Region Availability

MgC is available in AP-Singapore, TR-Istanbul, LA-Sao Paulo1, and LA-Santiago. 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 regions 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.

Server where Edge is installed
  • You are advised to prepare a Windows server for installing Edge in the source environment. The Windows server must be able to access the Internet.
  • The PowerShell version of the Windows server where the Edge is installed must be later than 3.0. You can run the $host command in the PowerShell command window to view 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 specifications

Automated installation of KVM drivers is not supported for cross-AZ migrations. You need to manually install KVM drivers on source servers that use Xen by referring to Installing KVM Drivers.

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 disk
  • Servers whose system disk is larger than 1 TB cannot be migrated.
  • You are advised not to migrate servers whose disk capacity exceeds 4 TB.

Source server status

Frozen source servers in the retention period cannot be migrated.

Target server
  • 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.

File systems

MgC cannot migrate files from 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 a domain

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 must not contain special characters.
  • A single object cannot be larger than 4.76837158203125 TB (500 MB x 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 creating a migration workflow.
    • After the migration is complete, manually create a symbolic link to the path at the target.
  • Migration of symbolic links is not supported for migration from NAS_SMB or migration from NAS_NFS to OBS.
  • For migration from NAS_NFS or Alibaba Cloud OSS to NAS_NFS, symbolic links can be migrated. To keep symbolic links valid after being migrated, enable metadata migration. Otherwise, the symbolic links will lose their link functionality and become regular files after the migration.
    NOTICE:

    If the objects that soft links point to are not completely migrated to the target, these soft 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.

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 correponding object will fail to be migrated.

    • English characters, digits, and hyphens (-) are directly migrated without code conversion.
  • For heterogeneous migrations, metadata cannot be migrated.

Archived data

To migrate archived data from object storage, you must restore it first. You need to:

  • Create migration workflows after the restoration is complete.
  • 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.

  • The files must be in .txt format, and their metadata Content-Type must be text/plain.
  • 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 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.
  • Soft links cannot be migrated.

Migration source: NAS file systems
  • The following types of files can be migrated: regular files, directory files, symbolic link files, and hard link files.
    CAUTION:

    If the file handle is occupied or the source file is deleted, the file will fail to be migrated.

  • 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.