#Virtual Machine Live Migration

#Overview

The virtual machine live migration technology allows for moving a virtual machine from one physical server to another without shutting down or interrupting the virtual machine. The platform's virtual machine solution is implemented based on the open-source component KubeVirt, which uses pre-copy memory migration by default.

#Pre-Copy

Pre-copy memory migration is a commonly used virtual machine migration technology that ensures service continuity during migration by pre-copying the virtual machine's memory data. The specific process is as follows:

1. Initial Phase: At the start of the migration, the source host will copy the virtual machine's memory pages to the target host while the virtual machine continues to run. Because the virtual machine continues running, some memory pages may be modified during the copying process.
2. Iterative Copying: The source host repeatedly copies the modified memory pages to the target host until the number of modified pages decreases to an acceptable level. Each round of copying is called an iteration, and the number of unmodified memory pages gradually decreases after each iteration.
3. Stop and Copy: When the remaining un-copied memory pages are sufficiently few, the virtual machine will pause briefly (usually only a few seconds to a dozen seconds), during which the last memory pages are copied to the target host, and the virtual machine's CPU and device states are synchronized to the target host.
4. Resume Operation: The virtual machine resumes operation on the target host.

#Constraints and Limitations

It is recommended that the two physical machines involved in the live migration operation use the same hardware configuration. If the configurations are inconsistent (for example, different CPU models), migration may fail.

#Prerequisites

Please enable the relevant virtual machine live migration functions in advance.

#Operation Steps

#Deploy kubevirt-operator

Note: For detailed steps and parameter explanations, please refer to Install.

1. Go to Administrator.

2. In the left navigation bar, click App Store Management > Operators.

3. Click Cluster at the top of the page to switch to the cluster where the Operator needs to be deployed.

4. In the OperatorHub tab, click Deploy on the KubeVirt HyperConverged Cluster Operator card.

5. Configure the parameters as needed and click Deploy. You can check the Operator deployment status in the Deployed tab.

#Create HyperConverged Instance

For specific creation steps, please refer to Create HyperConverged Instance.

#Prepare the Virtual Machine

Note: It is recommended to use the Kube-OVN Underlay network. For related configurations, please refer to Create Subnet (Kube-OVN Underlay Network).

1. Go to Container Platform.

2. In the left navigation bar, click Virtualization > Virtual Machine.

3. Click Create Virtual Machine.

4. Click More in the Basic Information area to expand more configuration options, and click Add corresponding to Annotations, adding annotations according to the key-value pairs below. If the network plugin is Kube-OVN, there is no need to manually fill in this annotation.

   Note: Due to form restrictions, please enter the value of the annotation first before entering the key of the annotation.

   	Annotation
   Value	true
   Key	kubevirt.io/allow-pod-bridge-network-live-migration

5. Configure other virtual machine parameters as needed. For specific parameter descriptions, please refer to the relevant product documentation.

   Parameter	Description
   Volume Mode	Must use Block Mode.
   Storage Class	Must use CephRBD block storage type storage class.
   Network Mode	Recommended to use Bridge.

6. Click Create.

#Start Live Migration

Note: Live migration can only be started when the virtual machine status is Running.

1. Go to Container Platform.

2. In the left navigation bar, click Virtualization > Virtual Machine.

3. Start the live migration. There are two ways to do this:

   • Click ⋮ > Live Migration on the right side of the virtual machine that needs to be migrated in the list.
   • Click the name of the virtual machine that needs to be migrated in the list to enter the detail information page, then click Actions > Live Migration.

4. Click Confirm. You can check the migration progress through Virtual Machine Status or Real-Time Events. When the status changes from Migrating to Running, or when a real-time event appears with information like Migrated: The VirtualMachineInstance migrated to node 10.1.1.1., it indicates that the migration was successful.

#Using the API

Start a live migration by creating a VirtualMachineInstanceMigration that names the running virtual machine instance:

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
  name: migrate-web-01
  namespace: demo
spec:
  vmiName: web-01

kubectl apply -f migration.yaml
# phase progresses Pending -> Scheduling -> Running -> Succeeded
kubectl get virtualmachineinstancemigration migrate-web-01 -n demo -o jsonpath='{.status.phase}{"\n"}'

When the phase is Succeeded, the instance is running on the target node — see VirtualMachineInstance.status.migrationState.targetNode. To cancel an in-progress migration, delete its VirtualMachineInstanceMigration object (there is no cancel field):

kubectl delete virtualmachineinstancemigration migrate-web-01 -n demo

#Migration Settings

Cluster-wide live-migration limits and per-namespace overrides are configured through the HyperConverged resource and cluster-scoped MigrationPolicy objects, as described below.

#Cluster defaults

The cluster defaults are the KubeVirt liveMigrationConfig, which is owned by the HyperConverged operator. Set it on the HyperConverged resource — never directly on KubeVirt, because the operator reconciles that value back:

kubectl get hyperconverged kubevirt-hyperconverged -n kubevirt -o jsonpath='{.spec.liveMigrationConfig}'
# {"parallelMigrationsPerCluster":5,"parallelOutboundMigrationsPerNode":2,
#  "completionTimeoutPerGiB":150,"progressTimeout":150,
#  "allowAutoConverge":false,"allowPostCopy":false}

#Namespace policies

A cluster-scoped MigrationPolicy overrides the defaults for the namespaces (or virtual machines) matched by its selector:

apiVersion: migrations.kubevirt.io/v1alpha1
kind: MigrationPolicy
metadata:
  name: policy-fast
spec:
  selectors:
    namespaceSelector:
      kubernetes.io/metadata.name: demo
  allowAutoConverge: true
  completionTimeoutPerGiB: 100

A virtual machine whose namespace matches no policy uses the cluster defaults.