Migrate a VM

Perform this task to migrate a VM between hosts and storages.

VM migration changes the carriers of a VM, including computing resources and storage resources. For example, you can change the host where a VM runs, or change the storage pool that stores disks (image files) of a VM.

VM migration types

Based on the VM state, VM migration includes online migration and offline migration.

Online migration—Migrates a running VM. To ensure a successful online migration, make sure the target host has enough memory before you migrate a VM.
Offline migration—Migrates a shutdown VM.

Based on the application mode, VM migration includes dynamic migration and manual migration.

Dynamic migration—VMs are dynamically migrated in a cluster when they are running. Dynamic migration occurs when hosts fail, resources are allocated unevenly, or DPM policies are configured. Dynamic VM migration is implemented through HA, DRS, and DPM configuration of a cluster.
Manual migration—VMs are migrated manually by an administrator. Manual migration is performed during maintenance to optimize system performance. For example, you can manually migrate the VMs on a host before you upgrade the hardware of the host. After the hardware upgrade, you can migrate the VMs back to the host.

Migration methods

Change host—Migrates a VM between hosts. This method is available only for VMs that use a shared storage pool, and the shared storage pool must be mounted to the migration destination host.
- When a host fails or is overloaded, you can migrate VMs on that host to other hosts to ensure VM service availability.
- When multiple hosts are in light-load state, you can migrate VMs on these hosts to one of them and shut down the other hosts to save resources.
- You can cancel online VM migration between hosts.
Change storage—Migrates the disks of a VM to another storage pool that is mounted to the host where the VM is running.
Change host and storage—Migrates a VM between hosts, and changes the storage pool to which its disks are attached. The destination host can be any host in the cloud resource, and the destination storage pool must be mounted to the destination host. Use this method when a VM uses a local disk or the disk of the VM is in a shared storage pool but the storage pool is not mounted to the destination host.

Table-1 Networks used in VM migration

VM state	Migration method
VM state	Change host	Change storage	Change host and storage
Online	Migration network and management network	Storage network	Migration network, management network, and storage network
Offline	Management network	Storage network	Migration network, management network, and storage network

Management network—Transmits control layer data between the management platform and hosts, including configuration information and control commands.
Storage network—Transmits packets from hosts to the storage. The storage network and management network can share the same IP range.
Migration network—Transmits service data during VM migration, including VM memory and disk image data. The migration network and management network can share the same IP range.

If you migrate the host and storage for a VM or migrate only the host for a VM, the system uses the following rules to select the networks:

If the migration networks of the source and destination hosts are available, the system uses the migration networks. During migration, the management networks are used to transmit configuration information and control commands.
If the migration networks of the source and destination hosts are unavailable, the system uses the management networks.

Wait timeout timer

The wait timeout timer refers to the maximum duration CVM waits for a migration result from a CVK host after it deploys a migration task to that CVK host. If CVM does not receive a migration result from the CVK host before the wait timeout timer expires, it will terminate the migration task. The wait timeout timer varies by VM migration method as follows:

If the VM migration method is Change host, the wait timeout timer is three days.
If the VM migration method is Change storage, the total wait timeout timer depends on the disk count of the VM. The disks will be migrated in sequence, and the wait timeout timer for each disk is three days.
If the VM migration method is Change host and storage, the VM is migrated between hosts after its disks are migrated to another storage pool in sequence. The wait timeout timer for each disk is three days, which is the same as that for host change.

Restrictions and guidelines

To avoid VM startup failure or slow VM startup after migration, make sure the target storage pool has sufficient space and the target host has enough CPU and memory resources.
For successful migration, make sure the available space of the target storage pool is larger than the storage volume size of a VM when you migrate the VM by using the Storage and Host and Storage migration type. If you change the disk format, you must also make sure the available space of the target storage pool is at least twice the space of the storage volume on the source VM. During the migration process, if other operations use too much storage space, the migration task might get stuck and unable to complete. In this case, you must manually clear the target storage space to ensure that there is enough free space to accommodate the VM disk files, allowing the migration task to complete successfully.
When you migrate a VM by using the Host or Host and Storage migration type, the VM list of the destination host might contain two entries about the VM before the migration is finished. After the migration is finished, only one entry about the VM is displayed in the VM list of the destination host.
If a VM has snapshots, you can only change the storage of the VM between file system type storage pools or between RBD storage pools in the same distributed storage system.
VMs that act as Kubernetes cluster nodes cannot be migrated to another cluster. If you migrate VMs across clusters in bulk, VMs that act as Kubernetes cluster nodes will be filtered out.
Migrating VM storage while a VM is online will rate limit disk I/O and might degrade service performance or cause other service issues. As a best practice, perform this operation while the service running on the VM is idle.
You cannot migrate a VM between an x86 host and an ARM host.
To avoid migration failures, do not shut down a VM during online migration of that VM.
During online migration of a VM, if a message displays that the VM is not installed with CAStools or CAStools is not running on the VM, you can ignore this message. This message is displayed because the migration has not completed before the alarm monitoring period expires and the system generates a false alarm.
VMs that use encrypted disks do not support online storage migration.
When you migrate an online VM that has multi-level images, remnant base images exist even if you cancel the migration task. You can delete the remnant base images from the storage pool.
Bulk online VM migration supports post-copy memory. When the VM migration task starts, you can click Details in the task console to view the migration progress. On the console, you cannot manually switch to post-copy memory state.

Procedure

On the top navigation bar, click Compute.
From the left navigation pane, select Resource Navigation > All > Resources > Host Pool Name > Host Name > VM Name or Resource Navigation > All > Resources > Host Pool Name > Cluster Name > Host Name > VM Name.
Click Migrate.
Follow the configuration wizard to migrate the VM.
To cancel the VM migration task, click Cancel in the Actions column for the migration task or click Details in the Actions column for the task and then click Cancel in the upper right corner of the page that opens.

Parameters

Select migration type:

Host: Migrate the VM to another host. This method applies to VMs that use shared storage pools. The target host and the destination host must use the same shared storage pool.
Storage: Migrate the disks of a VM to another storage pool that is mounted to the host to which the VM is attached.
Host and Storage: Migrate the VM to another host and migrate the disks of a VM to another storage pool that is mounted to the host to which the VM is attached. The target host can be any host in the same cloud resource.
Target Host: Select a destination host for migration if you migrate the VM by changing the host or both the host and storage.
Network Type: vSwitch network type of the selected target host. This parameter is automatically populated after you select a target host for a VM migration by changing the host.
Post-Copy Memory: Enable post-copy memory to ensure that VM migration finishes within the migration timeout period. This feature is available if you manually migrate a running VM by host. To avoid VM service interruption during the migration, make sure the storage resources and networks of the source and target operate correctly. Follow these restrictions when you use this feature:
- In the upgrade scenario, the post-copy memory feature has the following limitations:
  - For an upgrade from E0520 or earlier to E0730P08 or later, the post-copy memory feature is not supported for VMs running on the hosts that have completed the upgrade but have not yet restarted.
  - In the ARM host upgrade scenario, the post-copy memory feature is not supported for VMs migrating during the upgrade process from the E0730 series to the E0760 series.
  VMs with the following configurations do not support the post-copy memory feature:
  - VMs using DPDK virtual switches or smart NICs.
  - VMs with vGPUs.
  - Suspended VMs.
  - Post-copy memory is not supported when a VM has HugePage configuration enabled, but the source and destination hosts have different HugePage page sizes. To use the post-copy memory feature, the source and destination hosts must have the same HugePage page size.
  - VMs with HugePage enabled do not support post-copy memory when the migration network is a gigabit network.
Estimated Migration Duration: Estimated length of time that the system will use to migrate the running VM by changing the host. If a migration network is available between the source and destination hosts, the migration duration is estimated based on the migration network condition. If no migration network is available between the source and destination hosts, the migration duration is estimated based on the management network condition. As a best practice, enable post-copy memory for the migration if this duration is longer than 24 hours.
Initiative CPU Frequency Underlocking: Select whether to enable initiative CPU frequency underlocking. After you enable this feature, the system will reduce the CPU scheduling frequency of a VM to reduce the migration data and accelerate its migration. Enabling this feature might decrease VM performance. This feature takes effect only when you migrate a running VM by changing its host or changing both its host and storage.
Encryption: Set whether to encrypt the data to be transmitted during migration of a running or suspended by changing the host or changing the host and storage.

Configure destination storage:

Destination Storage Pool: Select a new storage pool for the VM disk. If the VM has multiple disks, you can select different storage pools for the disks.
Set Format: Specify the disk format. If the disk of a VM has base image files, the disk format cannot be changed. This parameter takes effect only if you select a destination storage pool of the local directory, shared file system, or NFS file system type.
- Same Format—The disk format keeps unchanged.
- Intelligent—The disk format is qcow2.
- High-Speed—The disk format is raw. This format has high I/O efficiency.
Migration Policy: Select a migration policy. This parameter is required only when you choose to migrate a VM by changing its storage or changing its host and storage.
- Migration First—Features fast VM migration. However, using this policy might cause VM I/O failure if VMs are busy. As a best practice, use this policy when VMs are relatively idle.
- Service First—Features slow VM migration. As a best practice, use this policy when VMs are busy.
Timeout: Set the migration timeout timer, which specifies the maximum running time for the VM migration task. The migration task is cancelled automatically when the migration timeout timer expires. To prevent a migration task from occupying system resources for a long time, configure a migration timeout timer for that migration task. If you leave this parameter empty, the migration timeout timer equals the default wait timeout timer. The migration task is cancelled automatically when the default wait timeout timer expires. For more information about the wait timeout timer, see "Wait timeout timer." This parameter is available only when you migrate a VM by changing its storage or by changing its host and storage.
Migration Rate Limit Policy: Select a migration rate limit policy. This parameter is available when you choose to migrate a VM by changing its storage or changing its host and storage.
- Auto—The system tunes the migration speed automatically based on the service latency of VMs.
- Custom—You manually set the migration speed for VMs.
Migration Speed: Set the storage data migration speed. This parameter is required only when you choose to migrate a VM by changing its storage or changing its host and storage and select the custom migration rate limit policy.
- Medium: Set the migration speed to about 20 Mbps. To save system resources, select this option.
- Fast: Set the migration speed to about 30 Mbps. Faster migration requires more system resources. If you select this option, migrate the VM when services are not busy.
- Unlimited: Do not limit the migration speed. The VM will be migrated at the maximum speed, and performance of running VMs will be affected. If you select this option, migrate the VM when system load is light.
- Limit Max Speed: Enable limiting the maximum migration speed. If you select this option, the system will set a default max speed. You can set a max speed as needed, in Mbps.

The migration speed parameter does not take effect if an offline VM is migrated between two RBD network storage pools.
The migration speed parameter does not take effect if the migrated VM is running and has internal snapshots.

Migration Acceleration: This feature relies on support of the XCOPY attribute and is suitable for data copying between different LUNs within the same physical storage. The acceleration process involves write amplification. As a best practice, use this feature to migrate VMs that are not sensitive to service latency. This parameter is required only when you choose to migrate a VM by changing its storage.