6.17.1 Moving a Guest Using Exadata VM Live Migration

Exadata VM Live Migration enables the seamless migration of a running Oracle Linux KVM guest to another KVM host.

The guest remains available throughout the operation, and normal processing continues with only a brief pause of less than four seconds during the switchover to the new KVM host.

The following general requirements apply to Exadata VM Live Migration:

  • The Exadata system hardware must be at least Oracle Exadata X10M.

  • The Exadata system must use Oracle Exadata System Software release 26.1.0 or later.

  • The Exadata system must be configured to use Exascale storage to host the guest image files.

  • The Exadata system must be configured with Exadata Secure RDMA Fabric Isolation (Secure Fabric) enabled.

  • The source and target KVM hosts must reside in the same Exadata system configuration and have the same network visibility.

  • The source and target KVM hosts must use the same model of server hardware, with the same number and type of CPUs.

  • The source and target KVM hosts must have access to the same Oracle Exadata storage servers.

  • The target KVM host must have sufficient free CPU and memory resources to accommodate the guest.

    • It is possible to over-commit virtual CPUs such that the total number of virtual CPUs assigned to all guests exceeds the number of physical CPUs on the system. Over-committing CPUs can be done only when the competing workloads for over-subscribed resources are well understood and the concurrent demand does not exceed physical capacity.

    • It is not possible to over-commit memory.

  • The guest name must not already be in use on the target KVM host.

The operation to move a guest using Exadata VM Live Migration occurs in multiple phases:

  1. The setup phase contains various checks and prepares the target KVM host to accept the migrated guest.

  2. During the memory migration phase, guest memory pages are copied to the target KVM host. Exadata VM Live Migration uses a pre-copy memory migration approach, meaning that the guest memory is copied to the target KVM host before the guest itself is moved. During this process, the guest remains fully operational on the original KVM host. Because the guest is still running, all memory changes must be tracked and modified memory pages must be re-copied to the target host before the final switchover.

    This phase typically accounts for most of the overall migration time. The actual duration depends on the total guest memory size and the amount of memory changed during the memory migration phase.

    If memory pages change faster than they can be copied to the target host, the memory migration phase cannot finish and the migration will time out. By default, an unfinished migration operation automatically cancels after 10 minutes. However, you can manually cancel a running migration at any time.

    To avoid issues and maximize performance, perform migration operations when the guest is not under heavy load.

  3. After the memory migration phase, the guest transitions to the target KVM host. The switchover completes quickly, so client connections remain available and application processing continues with only a brief pause of less than four seconds. During the switchover:

    • The target KVM host finalizes necessary resource allocation.

    • The network connection timeout is temporarily suspended to maintain the client network connections to the guest.

    • The guest pauses on the original KVM host, and runtime state information is transferred to the target KVM host.

    • The guest starts on the target KVM host.

    • A Gratuitous ARP (GARP) message is broadcast to ensure network traffic is routed correctly to the target KVM host.

You can perform Exadata VM Live Migration operations by using the Oracle Exadata Deployment Assistant (OEDA) Command Line Utility (OEDACLI) or by using the dedicated migratevm utility:

Parent topic: Moving a Guest to a Different KVM Host