VM migration is a resource scheduling feature implemented when SCP integrates with HCI. The following two migration types are supported: live migration (online migration) and cold migration (offline migration). Live migration changes the node or datastore where a VM runs without interrupting business services, suitable for maintenance and load balancing scenarios. Cold migration requires the VM to be powered off and is suitable for migration across clusters with compatible architectures (such as migration from a c86 cluster to an x86 cluster) or resource adjustments during non-business hours. Both migration types must follow the architecture and version constraints defined by HCI.

Core values: VM migration balances cluster load, prevents hardware failures, and improves performance across datastores. HCI uses the self-developed Sangfor4 compression algorithm, which increases the migration speed by over 7 times and lowers CPU usage by 80%, optimizes CPU throttling (downtime switch duration is 2 seconds or less), reduces the dirty data block size (disk dirty data amplification is reduced by over 90%), and ensures a business interruption of at most 3 seconds in heavy-load scenarios (such as an Oracle system with 1,000 users).
Supported versions and architectures: Migration is supported only for managed VMs that run HCI 6.7.0 or later. Live migration is restricted to clusters with the same architecture (such as migration from an x86 cluster to another x86 cluster, a c86 cluster to another c86 cluster, or an Arm cluster to another Arm cluster). Cold migration is supported for migrating VMs from a c86 cluster to an x86 cluster, but not from an Arm cluster to an x86 cluster. HCI 6.8.0 and later versions support cross-version live migration. After the migration is complete, perform a compatibility upgrade to enable all features for the migrated VMs.
Data transmission: VM migration involves the transmission of VM configuration, memory data, and disk data (required for cross-datastore migration). Static data is copied directly in cold migration. Data transmission in live migration contains three steps: full data transmission, incremental data sync, and downtime switch, ensuring a smooth business transition.
Principle of Live Migration
In live migration, the VM's CPU status data, memory data (with hot memory prioritized), and disk data (in cross-datastore migration scenarios) are transmitted via a TCP connection. The process contains three steps: full data transmission, incremental data sync, and downtime switch for remaining data, ensuring business continuity during the migration.
The following table describes supported migration types and the corresponding architecture requirements:

Migration Type	Scenario	Architecture Requirement	Version Requirement	Key Constraint
Intra-cluster live migration	Load balancing among cluster nodes and hardware maintenance for a single node	The source and destination clusters use the same architecture (x86, c86 or Arm).	No specific version requirement.	VMs with GPUs or raw disk mappings are not supported. If multiple network interfaces have the same bandwidth, the data communication port is used preferentially for migration.
Cross-cluster live migration - From x86 cluster to x86 cluster	Cross-data center expansion and disaster recovery for x86 clusters	The source and destination clusters both use the x86 architecture.	1. Live migration and cold migration are supported between clusters of the same version. 2. For clusters running HCI 6.0.0 R5, 6.2.0, and 6.3.0 Rx, the latest SP must be installed to support cross-version migration. 3. HCI 6.9.0 and later versions support migration to higher versions. 4. The cross-version migration feature is integrated into HCI 6.8.0 R2, with the same effect as the cross-version migration SP for HCI 6.8.0 and later. It is recommended to upgrade from HCI 6.8.0 R1 to HCI 6.8.0 R2. 5. Once a VM is migrated from a lower version cluster to a higher version cluster and upgraded from compatibility mode to all function mode, the VM cannot be migrated back to the lower version cluster.	After the migration is complete, the source VM is powered off and moved to Recycle Bin. Perform a compatibility upgrade for the migrated VM in the destination cluster and restart it for all features to take effect.
Cross-cluster live migration - From c86 cluster to c86 cluster	Load balancing between C86 clusters	The source and destination clusters both use the c86 architecture.	Same as above	If Host CPU is enabled for the VM to migrate, the source and destination nodes must support the same instruction set. Cross-cluster live migration is not supported between clusters with different architectures.
Cross-cluster live migration - From Arm cluster to Arm cluster	Disaster recovery for Arm (Kunpeng) clusters	The source and destination clusters both use the Arm architecture.	Same as above	GPU-enabled VMs and VMs with large memory are not supported.
Cross-cluster cold migration - From c86 cluster to x86 cluster	Transition from c86 to x86 (non-business hours)	The source cluster uses the c86 architecture, and the destination cluster uses the x86 architecture (c86 instruction set is supported).	Same as above	Only cold migration is supported (VM must be powered off). VM migration from an Arm cluster to an x86 cluster is not supported.
Cross-datastore live migration	Storage performance upgrade (such as upgrade from HDDs to SSDs) and storage load balancing	The source and destination use the same architecture (whether in the same cluster or in different clusters).	HCI 6.11.1 and later support specifying the IO speed limit.	The destination must be a virtual datastore (external storage is not supported). Set Datastore to the target virtual datastore when configuring the migration task.
Cold migration (general)	Resource adjustments during non-business hours and VM migration between lower version HCI clusters	Cold migration is supported between clusters with the same architecture or from a c86 cluster to an x86 cluster.	No specific version requirement.	After the migration is complete, the source VM is moved to Recycle Bin. VMs with shared virtual disks do not support cold migration.

Constraints and Restrictions

Live migration is supported only between clusters with the same architecture (migration from x86 to x86, from c86 to c86, or from Arm to Arm). VMs in an Arm cluster cannot be migrated to an x86 cluster. VMs in a c86 cluster support only cold migration to an x86 cluster that is compatible with the c86 instruction set.
To hot-migrate a VM with Host CPU enabled (which allows physical CPU passthrough), the source and destination nodes must support the same instruction set. Otherwise, the migration will fail. Due to system incompatibility, Host CPU must be disabled for Windows VMs with c86 architecture.
Live migration is not supported for VMs configured with GPUs (vGPUs or physical GPUs) or raw disk mappings. During cross-datastore live migration of VMs with shared virtual disks, the location of shared virtual disks remains unchanged.
Live migration is supported only for clusters in the classic network, not for clusters in VPCs. VMs with memory hot add enabled and VMs that have not been restarted after vmTools installation or uninstallation cannot be hot-migrated across clusters of different versions.
HCI 6.8.0 and earlier versions do not support cross-version live migration. For HCI 6.9.0 and later, VMs run in compatibility mode by default (some features are unavailable, and a compatibility upgrade is required) after cross-version migration.
Compressed transmission consumes up to 4 CPU threads. It is recommended to disable compressed transmission in high-bandwidth (≥ 10 Gbps) scenarios. VM performance decreases when CPU throttling is enabled. Therefore, enable CPU throttling only if migration failures occur during peak hours.
After the cross-cluster migration is complete, the source VM is automatically powered off and moved to Recycle Bin (retained and recoverable for 30 days). The source VM is not deleted after intra-cluster migration.

Steps

{{ $t('index.defaultHeader.logo') }}

Sangfor Cloud Platform (SCP)

Migration and Scheduling