Hyper Converged Infrastructure (HCI/aSV)

Sangfor HCI and aSV provide a unified infrastructure combining compute, storage, networking, and built-in security to simplify deployment, operations, and services.
{{ $t('productDocDetail.guideClickSwitch') }}
{{ $t('productDocDetail.know') }}
{{ $t('productDocDetail.dontRemind') }}
6.11.1R1
{{sendMatomoQuery("Hyper Converged Infrastructure (HCI/aSV)","Migrate a Running VM Across Clusters (Bulk Migration Supported)")}}

Migrate a Running VM Across Clusters (Bulk Migration Supported)

{{ $t('productDocDetail.updateTime') }}: 2026-01-05

Description

You can migrate a running VM to another HCI cluster. Cross-cluster hot migration is supported if the source and destination use CPUs from the same vendor.

Precautions

  1. Powered-off VMs can be migrated to another node and datastore.
  2. We recommend that you perform cross-cluster migration during off-peak hours, because data needs to be transmitted over the management network.
  3. After cross-cluster migration is completed, the source VM will be shut down and moved to the recycle bin.
  4. You can migrate multiple VMs across clusters simultaneously.
  5. Supports bulk migration of VMs and supports setting Concurrent Migration Tasks. Range: 1-50, default: 2.
  6. During bulk migration, the VMs must have the same destination datastore.
  7. During cross-cluster migration, HCI may report an image damage error for the destination side. This is because HCI detects images every 30 minutes and will report this error if the detected image is being migrated. Of course, the image is not damaged.
  8. Hot migration is not supported for VMs on which GPU allocation and RDM have been performed in the HCI console.
  9. HCI 6.9.0 and later support cross-cluster cross-version hot migration. Before the migration, you need to install the service pack for the source cluster. Then, the VM will undergo an in-place active upgrade, with up to one second of business jitter. After the migration, you need to upgrade the VM compatibility for the features of the new version to take effect. This process will restart the VM.

  1. Currently, the versions in the following table support cross-version hot migration.

Architecture

Source Version

Destination Version

x86

6.0.0 R5

6.9.0

6.2.0

6.3.0 R1

6.3.0 R2

6.3.0 R3

6.7.0 R2

6.3.0 R1 (EN)

6.9.0 (EN)

6.3.0 R2 (EN)

Some kernel features take effect only after a restart.

Version

Feature Restriction

6.0.0 R5

The maximum memory is 960 GB.

You cannot change the operating system of VMs.

L3 cache is not supported.

Disk space deallocation is not supported.

Anti-escape is not supported for VMs.

You cannot use a VirtIO NIC for a VM if vmTools is not installed on the VM.

6.2.0, 6.3.0 R1, and 6.3.0 R2

You cannot change the operating system of VMs.

L3 cache is not supported.

Disk space deallocation is not supported.

Anti-escape is not supported for VMs.

You cannot use a VirtIO NIC for a VM if vmTools is not installed on the VM.

  1. After the cross-cluster cross-version hot migration, if you restart the VM without clicking Upgrade VM Compatibility, the VM is still a compatible VM.
  2. The following are restrictions on some of the features of a compatible VM after the cross-cluster cross-version hot migration:

If you export a compatible VM and then import it, the imported VM will not be a compatible one but a full-featured VM.

If you back up a compatible VM and then recover it, the recovered VM will not be a compatible one but a full-featured VM.

If you snapshot a compatible VM and then recover or clone it based on the snapshot, the new VM will not be a compatible one but a full-featured VM.

If you clone a compatible VM, the new VM will not be a compatible one but a full-featured VM.

  1. If you enable migration optimization, the VM will undergo an in-place active upgrade with up to 1 second of business jitter.
  2. After CPU Throttling is enabled, the IOPS of the VMs will be significantly reduced during the migration.
  3. The following are scenario-specific restrictions on the cross-version hot migration of some special VMs.

  1. The following are further scenario-specific restrictions of cross-version hot migration:

You can perform migration among clusters on the classic network but not VPC.

Migration optimization is not supported for a VM if you have configured its memory hot add settings when it is powered on or if you have not restarted it after installing or uninstalling vmTools.

Cross-QEMU cluster migration is not supported if the underlying system of the host is UOS.

VMs using shared virtual disks do not support cross-cluster live migration.

Prerequisites

The source VM can properly access the interface used for migration to the destination host, and the VM migration service has been enabled on the Port Management page.

Steps

  1. Select the target VM. In detail, go to Compute > List, select the target VMs, and go to More > Migrate Across Clusters.

  1. Enter information about the destination cluster, including Cluster IP, Super Administrator, and Password. Then, click Next.

 

  1. Set Datastore, Storage Policy, and Destination Node. Click Advanced, configure the Network and Migration Speed, and select Enable compressed transmission and CPU Throttling as needed.

Network: Automatically identifies the interface bandwidth. When the bandwidths of the management interface, overlay network interface, and storage network interface are inconsistent, the interface with the highest bandwidth is recommended first. When the bandwidths of the interfaces are consistent, they are recommended under the rule of overlay network interface > storage network interface > management interface.

Migration Speed: Unlimited by default. You can set the maximum speed before or during the hot migration to be at least 10 MB/s and at most the bandwidth of the physical interface of the migration network.

Enable compressed transmission: If enabled, hot migration will be accelerated but additional CPU resources (up to four threads) may be used.

CPU Throttling: Recommended to be enabled when the platform is busy or under heavy workloads. If enabled, the CPU performance of VMs will be limited to reduce the data generation speed to ensure efficient VM migration.

  1. Optimize the VMs before cross-version hot migration as required. Specifically, click Optimize to perform an in-place active upgrade on the VMs. Then, QoS limiting and CPU throttling are available for a better migration experience.

  1. Click Next and configure the NIC.

  1. Click OK. When the Message dialog box is displayed, click Migrate to start cross-cluster hot migration.

  1. During the migration, view the migration progress in the Status column and suspend the VMs as required. Upon VM suspension, businesses will be stopped for a period of time to prevent the VMs from generating new memory data before migration is completed. We recommend that you suspend VMs during off-peak hours.

 

  1. In cross-cluster cross-version hot migration scenarios, the VMs will be in compatible mode after being migrated to the destination cluster, and some of their features will be restricted. Therefore, you need to go to the VM details page and go to More > Upgrade VM Compatibility to restart the VM for the features to become available.

After the cross-cluster cross-version hot migration, we recommend that you upgrade the VM compatibility during off-peak hours.

After the cross-version hot migration and before the VM compatibility upgrade, if you find that the VM businesses are abnormal, you can migrate them back to the source cluster. If you have upgraded the VM compatibility, this operation is not allowed.