Tigera Logo

Guides: Kubevirt Live Migration

KubeVirt Live Migration: From Basic to Advanced

What Is KubeVirt Live Migration

KubeVirt live migration enables the movement of running virtual machines (VMs) between Kubernetes nodes without noticeable downtime. Unlike traditional VM migrations, KubeVirt leverages Kubernetes’ native APIs to orchestrate and manage live migration, making it a process for cloud-native environments.

During migration, the virtual machine continues to operate, minimizing service interruptions and providing high availability during infrastructure maintenance or scaling events. Live migration in KubeVirt is crucial for workloads requiring continuous uptime and is useful in scenarios such as planned hardware upgrades, load balancing, or responding to node failures.

The process involves transferring the memory, device state, and network connectivity of the VM, while I/O and memory changes are synchronized with the new host. KubeVirt manages these operations automatically, abstracting much of the complexity from cluster operators and developers.

Because KubeVirt runs VMs inside pods on shared Kubernetes nodes, live migration inherits the same trust boundaries as the rest of the cluster, making container security practices a foundational concern for any team operating migrating workloads at scale.

More broadly, Kubernetes security practices such as network segmentation, policy enforcement, and workload visibility extend naturally to VM-based workloads managed through KubeVirt.

In this article:

Benefits and Use Cases of KubeVirt Live Migration

KubeVirt live migration brings practical advantages to organizations running virtualized workloads in Kubernetes. By minimizing downtime and automating migration tasks, it enhances infrastructure flexibility and operational efficiency.

Key benefits:

  • Non-disruptive maintenance: Migrate VMs away from nodes undergoing maintenance without halting workloads, allowing system updates or hardware servicing without affecting uptime.
  • Balancing workloads across nodes: Dynamically redistribute VMs to optimize resource usage and performance, reducing the risk of resource contention on overutilized nodes.
  • Enabling node upgrades or draining operations: Smoothly relocate VMs during node upgrades or planned node shutdowns, supporting seamless cluster lifecycle management.
  • Improving workload availability: Maintain service continuity during infrastructure events by ensuring VMs remain operational and reachable throughout the migration process.
  • Multi-tenant operations without downtime: Support uninterrupted service for multiple tenants by migrating workloads transparently, even during scaling or infrastructure adjustments.

Common use cases:

  • Planned infrastructure upgrades: Move VMs off nodes that need firmware or OS updates without interrupting applications.
  • Energy saving in data centers: Consolidate workloads on fewer nodes during low usage periods and power down idle nodes.
  • Cluster scaling operations: Rebalance VMs when scaling nodes up or down to maintain even resource distribution.
  • Policy-driven automation: Integrate with custom controllers or operators to automatically trigger migration based on metrics or policies.

How Live Migration Fits into KubeVirt Architecture

Live migration in KubeVirt operates as a native Kubernetes construct, tightly integrated with its control plane and resource management mechanisms.

KubeVirt extends the Kubernetes API through custom resource definitions (CRDs), specifically the VirtualMachineInstance (VMI) and Migration objects. When a live migration is triggered, a Migration object is created, which instructs the KubeVirt controller to begin the migration process for the target VMI.

The KubeVirt handler on the source and destination nodes manages the actual data transfer. The source node streams memory pages and device state over a secure channel to the destination node using a protocol based on QEMU’s migration capabilities. The destination node prepares a corresponding VMI pod to receive the migrated VM state and resume execution.
The Kubernetes scheduler plays a role by selecting an appropriate destination node that meets resource and affinity constraints. Meanwhile, the KubeVirt controller manages the lifecycle of the migration, monitoring progress and ensuring rollback or completion as needed.

Throughout the process, KubeVirt relies on Kubernetes primitives (pods, services, and custom controllers) to ensure that the VM remains discoverable and network-attached, without the VM itself being aware of the underlying migration. This architectural approach allows live migration to function seamlessly within Kubernetes-native workflows.

These same architectural primitives underpin vendor distributions of KubeVirt, such as OpenShift KubeVirt, which package the live migration controller and CRDs into enterprise Kubernetes platforms.

Learn more in our detailed guide to KubeVirt architecture

How KubeVirt Live Migration Works

KubeVirt live migration is built on the principles of memory synchronization and process handoff, using techniques derived from hypervisor-based VM migration. The core mechanism is based on QEMU’s live migration features, orchestrated through Kubernetes-native constructs.

Pre-Copy vs Post-Copy Migration

KubeVirt primarily uses pre-copy migration. In this model, the source node begins by sending memory pages to the destination while the VM continues running. During this stage, if a memory page changes after being sent (a “dirty” page), it must be resent. This process iterates until the number of dirty pages is small enough to allow a quick switchover. Once the memory difference is minimal, the VM is briefly paused, and the remaining memory and CPU state are transferred to the destination, where the VM resumes.

Post-copy migration, where execution starts at the destination before all memory is transferred, is not currently supported in KubeVirt due to its complexity and higher risk of failure in the event of network issues.

Memory Syncing and Dirty Page Copying

Memory synchronization is handled incrementally during pre-copy. The KubeVirt handler tracks changes to memory pages and retransmits only the dirty ones in subsequent rounds. This reduces downtime by minimizing the data that needs to be copied during the final pause. The process uses QEMU’s dirty page tracking mechanism, integrated into the KubeVirt migration flow.

Pause and Resume Behavior

When the migration enters its final phase, KubeVirt briefly pauses the VM on the source node to ensure consistency. The remaining dirty memory pages, CPU registers, and device states are transferred, and the VM is then resumed on the destination node. This pause is typically under a second, keeping service disruption minimal and often unnoticeable to users.

Pod and VM Lifecycle Interactions

The live migration process involves interaction between multiple pods and VM lifecycle controllers. When a migration starts, KubeVirt spawns a new pod on the target node to host the incoming VM. This pod is provisioned using the same configuration as the original and prepared to receive the migrated state.

During the transition, Kubernetes ensures both pods (the source and destination) exist concurrently, though only one is active at a time. Once migration completes, the source pod is terminated, and the new pod assumes full operation of the VM. The VirtualMachineInstance (VMI) object is updated to reflect the new node assignment, ensuring that service discovery and monitoring remain accurate post-migration.

Quick Tutorial: Configuring and Enabling KubeVirt Live Migration

This tutorial shows how to configure and enable KuberVirt Live Migration. Instructions are adapted from the official KubeVirt documentation.

Enabling the Feature and Triggering Live Migration

Live migration in recent versions of KubeVirt is enabled by default. However, for clusters running versions earlier than v0.56, you need to manually enable the feature by updating the KubeVirt custom resource (CR) and adding LiveMigration to the featureGates list.

To trigger a live migration, you can create a VirtualMachineInstanceMigration (VMIM) object. For example, to migrate a VM named vmi-fedora, define a resource with the following structure:

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: vmi-fedora

Alternatively, you can initiate migration using the virtctl CLI tool:

virtctl migrate vmi-fedora

KubeVirt calculates whether a virtual machine is migratable at startup and stores this in the VMI.status.conditions field. For a VM to support live migration, its volumes must support the ReadWriteMany access mode. If this condition is not met, the migration request will be denied.

The method of migration, either BlockMigration or LiveMigration, is also determined during VM startup. BlockMigration involves transferring disk data, while LiveMigration transfers only memory and state, reducing overhead.

Monitoring Migration Status

To monitor migration status, inspect the VMI status. Completed migrations will indicate timestamps and source/target nodes. If a migration is aborted, the status will reflect that it was canceled and whether it succeeded.

You can also cancel an active migration using:

virtctl migrate-cancel vmi-fedora

Deleting the migration object also cancels the process.

Cluster-Wide Settings

For better control over migration behavior, you can adjust cluster-wide settings in the KubeVirt CR. These include:

  • parallelMigrationsPerCluster: Max concurrent migrations across the cluster
  • parallelOutboundMigrationsPerNode: Max outbound migrations per node
  • bandwidthPerMigration: Bandwidth cap per migration (e.g., 64Mi)
  • completionTimeoutPerGiB: Time allowed per GiB to complete migration
  • progressTimeout: Max time without progress before the migration fails

Administrators can also configure workload disruption behavior. The allowWorkloadDisruption setting determines how aggressive KubeVirt is during difficult migrations:

  • Disabled (default): Migration will cancel if it cannot complete in time
  • Enabled: Allows the migration controller to switch to post-copy mode or pause the VM if needed to ensure completion

To enable these behaviors:

spec:
  configuration:
    migrations:
      allowWorkloadDisruption: true
      allowPostCopy: true

These settings provide fine-grained control over migration performance and risk, and can be tailored per VM group using migration policies.

Challenges in Operating KubeVirt Live Migration at Scale

As organizations scale up their use of KubeVirt across large or multi-tenant Kubernetes clusters, the operational complexity of managing live migration grows significantly. Key challenges include:

  • Ensuring adequate network bandwidth for migration traffic: Live migrations involve continuous memory synchronization and final state transfer, which can consume substantial network bandwidth. In clusters with many concurrent migrations or high-throughput workloads, insufficient bandwidth can delay migrations or cause them to fail. Operators must reserve or throttle bandwidth to prevent saturation.
  • Preventing migration traffic from interfering with workload traffic: Sharing network interfaces between workload and migration traffic risks performance degradation. To isolate these flows, consider using dedicated network interfaces, traffic shaping, or Kubernetes network policies that prioritize application traffic.
  • Maintaining security boundaries during node-to-node data transfers: Migrations transfer memory and device state over the network, making encryption and authentication critical. All communication between KubeVirt components should occur over secure channels (e.g., mTLS), and RBAC must be enforced to limit who can initiate migrations.
  • Detecting failed or slow migrations: At scale, it’s difficult to manually track each migration’s progress. Operators need to rely on observability tools and KubeVirt’s built-in timeouts (e.g., progressTimeout, completionTimeoutPerGiB) to automatically detect and recover from stalled or failing migrations.
  • Troubleshooting black-box failures: Migration failures often involve multiple layers: QEMU, network, storage, and Kubernetes itself. Without detailed logs or tracing, root cause analysis can be time-consuming. Enabling verbose logging, collecting system metrics, and using centralized observability platforms can simplify troubleshooting.
  • Ensuring observability into network flows: Understanding which nodes are communicating, at what rate, and for what duration is crucial during migrations. Integrating flow logging or using tools like eBPF-based observability (e.g., Cilium) helps track live migration behavior and identify bottlenecks.
  • Supporting multi-tenant or regulated environments: In multi-tenant clusters, resource isolation is key. Live migrations must honor tenant boundaries, prevent data leakage, and comply with governance policies. Configurations like node selectors, taints, and custom migration policies help restrict where VMs can move, ensuring compliance and performance isolation.

Best Practices for Reliable KubeVirt Live Migration

Organizations should consider the following practices when migrating KubeVirt.

1. Enable Auto-Convergence for High-Memory Workloads

Auto-convergence is a technique used to assist migration completion for memory-intensive workloads that continually mutate memory during the process. By gradually throttling CPU usage, auto-convergence limits the rate at which “dirty” memory pages are generated, allowing the migration process to synchronize the memory state more efficiently.

In KubeVirt, enabling auto-convergence is essential for VMs with high memory activity, as it prevents indefinite migration times or failures caused by an inability to reduce these dirty pages below acceptable thresholds. To enable this, operators set allowAutoConverge: true within the KubeVirt CRD configuration. This allows the hypervisor layer to engage auto-converge mechanisms during migration.

2. Isolate Migration Traffic from Workload Traffic

Migration operations can generate substantial network traffic, particularly when transferring large memory snapshots between nodes. If this data traverses the same network paths as application workload traffic, it can cause congestion, increase latency, and degrade the end-user experience. Isolating the migration traffic ensures that migrations proceed efficiently without impacting the network quality for regular VM operations or other cluster services.

Network isolation can be achieved by configuring dedicated VLANs, network interfaces, or Kubernetes network policies to separate migration data from routine application traffic. In environments that support multi-network interfaces, administrators can assign migrations to a specific network, reducing cross-talk and bottlenecks.

3. Configure Appropriate Migration Timeouts

Defining suitable migration timeout values is critical for ensuring predictable and reliable live migrations. Default timeout settings may not account for larger or more demanding VMs, potentially causing migration to abort prematurely if data transfer rates are insufficient. Resolving this involves adjusting migration timeout parameters in the KubeVirt configuration, such as bandwidthPerMigration and completionTimeoutPerGiB, to match VM memory sizes, expected workloads, and cluster performance characteristics.

The objective is to balance safety and efficiency: timeouts should prevent migrations from stalling indefinitely but avoid terminating processes that would otherwise complete successfully given more time. Review VM workload profiles and past migration durations when tuning these values.

4. Regularly Test Migration in Staging Environments

Routine testing of live migration processes in staging or test environments allows teams to identify and resolve issues before they impact production. Simulations should include a variety of VM configurations, workload types, and cluster scenarios, such as maintenance, failed nodes, or resource contention. These tests reveal performance bottlenecks, networking problems, or storage compatibility issues that may be masked under normal operations.

Incorporate migration testing into change management protocols, such as before cluster upgrades, network reconfiguration, or storage backend replacements. Automated testing suites can standardize these processes and provide timely feedback on migration reliability. Successful practices in staging can then be adapted to production.

5. Monitor Metrics via Alerting Tools

Effective monitoring is vital for maintaining high availability and performance during live migration. KubeVirt exposes relevant migration and VM state metrics through Prometheus endpoints, which can be integrated with cluster-wide monitoring and alerting tools such as Grafana or Alertmanager.

Track key indicators like migration duration, success and failure rates, bandwidth utilization, and resource saturation to promptly identify emerging issues during routine operations. Configuring alerts on migration failures, prolonged migrations, or infrastructure performance anomalies allows operators to respond quickly and address root causes before they escalate.

6. Apply Fine-Grained Network Policies to Migration Traffic

Restricting migration traffic through Kubernetes network policies enhances both security and network reliability. By default, migration data moves between nodes over the cluster network, which can expose VMs to lateral movement risks or allow traffic to interfere with unrelated workloads. Fine-grained policies enable precise control over which nodes and services can participate in live migrations.

Operators should define network policies that explicitly allow only authorized KubeVirt components, such as virt-launcher and virt-handler pods, to communicate over the ports used for live migration (typically TCP 49152–49215). In multi-tenant clusters, use namespace-based or label-based selectors to isolate migration traffic within tenant boundaries.

7. Ensure Observability and Traceability for Migration Flows

Deep visibility into migration flows is critical for diagnosing performance issues, ensuring auditability, and improving overall reliability. KubeVirt surfaces migration metrics through Prometheus, but for detailed flow analysis, teams should integrate with observability tools capable of capturing real-time data transfers, latencies, and node-to-node communication patterns.

Tools such as Cilium with Hubble, Istio, or eBPF-based tracing frameworks can provide low-level flow logs and dependency maps during live migration. Capture metrics like migration start time, transfer rates, dirty page iterations, and final switchover duration. Trace logs should be tagged with VM identifiers, node names, and timestamps to support post-mortem analysis or compliance audits.

8. Validate Compliance Requirements for Data Movement

In regulated environments (e.g., healthcare, finance, government), live migrations must comply with policies around data residency, encryption, and audit logging. Migrating VMs across geographic or logical boundaries may violate compliance rules if not properly controlled. Before enabling migration, validate storage backends and network paths against data sovereignty constraints.

Use node affinity, taints, and tolerations to restrict VM placement to approved zones or hosts. Enable encrypted communication channels (e.g., mTLS) for all migration data transfers, and enforce RBAC policies to limit who can initiate or cancel migrations. Audit trails must capture migration events, including source and destination nodes, timestamps, initiator identity, and outcome.

Evaluation Criteria for Live Migration Networking and Security

Support for Enforcing Network Policies on VM and Pod Workloads

KubeVirt supports standard Kubernetes NetworkPolicy objects, allowing fine-grained control over ingress and egress traffic to virtual machines. Each VM is backed by a pod (virt-launcher), which makes it possible to apply network policies as with any other Kubernetes pod.

Administrators can define policies to restrict traffic by namespace, label, IP block, or port, ensuring VMs can only communicate with authorized services. For environments using Calico or Cilium, policies can be extended with additional capabilities such as global policies, DNS-based rules, or L7 inspection. This enables secure segmentation of workloads.

Ability to Isolate Migration Traffic with Zero-Trust Principles

Live migration traffic includes memory pages, CPU state, and device information, transferred between nodes over the network. To implement zero-trust principles, this traffic must be both isolated and encrypted. KubeVirt supports secure transport using mutual TLS (mTLS) for communication between virt-handler, virt-launcher, and other KubeVirt components.

To further isolate traffic, administrators can configure multi-network support via the Multus CNI plugin, assigning a dedicated migration network interface. This ensures migration flows do not share the same path as application data. Combined with network policies, firewall rules, and role-based access control (RBAC), this setup minimizes lateral movement risk and unauthorized access during migrations.

Visibility into Migration Flows for Troubleshooting and Auditing

Detailed visibility into how data flows during migration is essential for diagnosing failures, performance regressions, or policy violations. KubeVirt surfaces basic metrics (e.g., migration duration, state transitions, bandwidth usage) via Prometheus. To go deeper, teams can integrate Cilium Hubble or eBPF-based tools to trace real-time network flows, observe node-to-node communications, and inspect protocol behavior.

Flow logs and telemetry should include timestamps, source/destination node IPs, port usage, and VM identifiers. For auditability, log aggregation tools such as Fluentd, Loki, or the ELK stack can store and correlate migration events with other system activities for post-incident reviews or compliance reports.

Real-Time Monitoring and Alerting for Migration Anomalies

KubeVirt emits key metrics that can be used to build dashboards and alerts for live migration monitoring. These include:

  • kubevirt_vmi_migration_running
  • kubevirt_vmi_migration_failed
  • kubevirt_vmi_migration_duration_seconds.

Alerts can be set to trigger on prolonged migration duration, repeated failures, excessive dirty page iterations, or bandwidth saturation. Integration with Prometheus Alertmanager, Grafana, or third-party systems like Datadog or Opsgenie ensures timely notification.

Compliance Reporting on Data Movement

Live migration must comply with policies regarding data locality, encryption, and access auditing, especially in finance, healthcare, or government sectors. To meet these requirements, KubeVirt logs must capture who initiated the migration, the VM involved, source and destination nodes, and timestamps.

Audit logs should be exported to secure and tamper-resistant logging platforms for retention. For data residency, node selectors, affinities, and taints can restrict VMs to compliant zones. Encryption of migration traffic via mTLS ensures data confidentiality in transit.

Scalability for High Volume / Large VM Environments

In large-scale clusters with many active VMs, running multiple migrations in parallel can overwhelm network and compute resources. KubeVirt allows configuration of parallelMigrationsPerCluster and parallelOutboundMigrationsPerNode to control concurrency. These settings prevent node saturation and avoid impacting live workloads during high-volume migrations.

For large VMs (e.g., >32 GiB memory), tuning parameters like bandwidthPerMigration and enabling auto-converge or post-copy modes can improve reliability. Clusters should also monitor resource usage (CPU, memory, disk I/O) during migrations and schedule them during low-traffic windows or via automation tools that adjust timing based on telemetry.

Multi-Cluster Consistency If Migrations Span Multiple Clusters

KubeVirt does not natively support cross-cluster live migration. However, organizations operating federated or multi-cluster environments can maintain consistency through policy replication and infrastructure standardization.

VM images and PersistentVolumeClaims must be accessible in each cluster, typically via distributed or replicated storage systems. Network identity (IP, DNS) and service discovery must also remain stable across clusters. While live migration between clusters must be orchestrated manually or via custom automation, planning for consistency ensures VMs can be rehydrated.

Enhancing Live Migration Security and Visibility with Tigera’s Calico

Calico extends the VM’s existing Layer 2 segment into the Kubernetes cluster and tracks its IP, VLAN, and MAC across nodes, so a KubeVirt live migration becomes a node-to-node compute event rather than a network reconfiguration event. The same data plane that preserves network identity also provides eBPF-based flow visibility and Kubernetes-native policy enforcement on the VM’s interfaces, giving migrated workloads the security and observability posture expected of any other workload in the cluster.

  • Calico L2 Bridge Networks for VM network continuity. Calico creates a bridge on each cluster node and attaches a trunk interface, allowing the VM’s original VLAN, IP address, and MAC address to be carried directly into Kubernetes through a secondary interface (net1) on the virt-launcher pod. Multiple VLANs can share the same trunk-backed bridge, so the existing Layer 2 topology is preserved without per-VLAN infrastructure.
  • Declarative network configuration. Administrators define a Kubernetes network resource that tells Calico which VLAN to bridge and how to map it, and a `NetworkAttachmentDefinition` instructs KubeVirt to attach the secondary interface at boot. Migration tooling such as Forklift maps existing VM interfaces to these definitions and registers the VM’s IP with Calico before cutover.
  • IP tracking across live migration. Once Calico owns the VM’s IP, it maintains routing state and follows the VM as KubeVirt moves it between nodes, so the same IP, VLAN, and MAC remain bound to the workload after migration. From the upstream network’s perspective the VM has not moved, which means firewall rules, DNS records, load balancer backends, and monitoring targets continue to resolve without change.
  • eBPF-based observability for VM interfaces. Calico provides traffic flow data, communication patterns, and east-west visibility for VM interfaces using eBPF, without requiring per-host agents, taps, or external monitoring tooling. This visibility applies to the same interfaces both before and after a live migration, giving consistent flow telemetry as VMs move across nodes.
  • Kubernetes-native network policy on VM interfaces. Calico network policy can be applied directly to VM interfaces using the same label and selector model used for containers, with selectors that can target specific VLANs or external networks. Existing hypervisor firewall rules can be migrated incrementally into version-controlled, auditable Calico policy without disrupting the workload or its live-migration behavior.

Next Steps

X