Virtual Machine Live Migration

Overview

Virtual machine live migration technology allows 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 by default uses a mode called ProCopy for live migration.

ProCopy

ProCopy (Pre-Copy Memory Migration) is a commonly used virtual machine migration technology that ensures service continuity during migration by pre-copying the memory data of the virtual machine. The specific process is as follows:

1. Initial Phase: At the start of the migration, the source host copies the virtual machine’s memory pages to the target host while the virtual machine continues to run. Since the virtual machine continues to run, some memory pages may be modified during the copying process.
2. Iterative Copying: The source host copies the modified memory pages to the target host multiple times until the number of modified pages is reduced 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 number of remaining un-copied memory pages is sufficiently small, the virtual machine is briefly paused (usually only a few seconds to a dozen seconds). During the pause, the final memory pages are copied to the target host, and the CPU and device states of the virtual machine 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 live migration have the same hardware configuration. If the configurations are inconsistent (e.g., different CPU models), the migration may fail.

Operation Steps

Note: All the following commands must be executed on the master node of the cluster where the virtual machine resides.

Deploy kubevirt-operator

Tip: For specific steps and parameter explanations, please refer to Deploy Operator .

1. Go to Platform Management.

2. In the left navigation bar, click Catalog > Operators.

3. Click Cluster at the top of the page to switch to the cluster where you want to deploy the Operator.

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

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

Create HyperConverged Instance

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

Update Configuration

Note: Ensure that the kubevirt-operator has been successfully deployed before performing this step.

1. Create a script file named kubevirt-config-update.sh on the Master node of the cluster where Kubevirt resides, and copy the following commands into this script file.

   #!/bin/bash
   
   # Check if the image repository address is provided
   if [ -z "$1" ]; then
     echo "Please provide the image repository address as a parameter, e.g., ./script.sh 192.168.1.100:10443"
     exit 1
   fi
   
   IMAGE_REPO=$1
   
   # Get the name of the first virt-operator pod
   POD_NAME=$(kubectl get pods -n kubevirt -l name=virt-operator -o jsonpath='{.items[0].metadata.name}')
   
   if [ -z "$POD_NAME" ]; then
     echo "Failed to get the name of the virt-operator pod. Please check if kubevirt-operator is running properly."
     exit 1
   fi
   
   # Get the Launcher image information
   VIRT_LAUNCHER_IMAGE=$(kubectl get pod $POD_NAME -n kubevirt -o yaml | grep -A1 VIRT_LAUNCHER_IMAGE | grep value | awk '{print $2}')
   
   if [ -z "$VIRT_LAUNCHER_IMAGE" ]; then
     echo "Failed to get VIRT_LAUNCHER_IMAGE. Please check if kubevirt-operator is running properly."
     exit 1
   fi
   
   # Replace build-harbor.alauda.cn with the provided IMAGE_REPO in VIRT_LAUNCHER_IMAGE
   NEW_VIRT_LAUNCHER_IMAGE=$(echo $VIRT_LAUNCHER_IMAGE | sed "s|build-harbor.alauda.cn|$IMAGE_REPO|")
   
   # Create patch.json file
   cat <<EOF > patch.json
   [
     {
       "op": "add",
       "path": "/spec/config",
       "value": {
         "env": []
       }
     },
     {
       "op": "add",
       "path": "/spec/config/env/-",
       "value": {
         "name": "VIRT_LAUNCHER_IMAGE",
         "value": "$NEW_VIRT_LAUNCHER_IMAGE"
       }
     }
   ]
   EOF
   
   # Execute kubectl patch command
   kubectl patch subscriptions.operators.coreos.com kubevirt-operator -n kubevirt --type='json' -p "$(cat patch.json)"
   
   # Check if the command was successful
   if [ $? -eq 0 ]; then
     echo "Successfully updated VIRT_LAUNCHER_IMAGE to $NEW_VIRT_LAUNCHER_IMAGE"
   else
     echo "Update failed. Please check the configuration and commands."
     exit 1
   fi

2. Execute the following command to update the script configuration. You need to pass the image repository address of the current environment as a parameter to the script.

   chmod +x kubevirt-config-update.sh
   ./kubevirt-config-update.sh <Registry Address>  # Replace <Registry Address> with the image repository address of the current environment

3. After the script executes successfully, the Operator will automatically update Kubevirt components such as the virt-controller.

   Note: After the script execution is complete, please wait 10 minutes before proceeding with subsequent operations.

Prepare the Virtual Machine

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

1. Go to Container Platform.

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

3. Click Create VM.

4. Click More in the Basic Info area to expand more configuration items, and click Add corresponding to Annotations to add annotations according to the following key-value pairs.

   Note: Due to limitations in the form, please fill in the Value of the annotation first, and then fill in the Key.

   	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.
   StorageClass	Must use a CephRBD block storage type storage class.
   Network Mode	Recommended to use Bridge.

6. Click Create.

7. When the virtual machine is running normally, check the YAML file of the virtual machine. If the status.conditions field already contains a condition with type: LiveMigratable and the status under this condition is True, it indicates that the virtual machine is ready for live migration.

Initiate Live Migration

Note: The following commands must be executed on the Master node of the cluster where the virtual machine resides.

1. Execute the following command in the CLI tool to initiate live migration. This command will trigger the virtual machine to migrate from the current node to the target node.

   kubectl create -f - << EOF
   apiVersion: kubevirt.io/v1
   kind: VirtualMachineInstanceMigration
   metadata:
     name: migrate-vm
     namespace: <namespace>  # Replace <namespace> with the namespace of the virtual machine
   spec:
     vmiName: <vm-name>  # Replace <vm-name> with the name of the virtual machine
   
   EOF

2. Execute the following command to check the migration status.

   kubectl get -n <namespace> vmi <vm-name> -o yaml # Replace <namespace> with the namespace of the virtual machine, and <vm-name> with the name of the virtual machine

3. By checking the status.migrationState field, you can monitor the migration progress and status. For detailed information about the migrationState field, please refer to the official website documentation .