Prerequisites

• The Exadata system must use 2-socket Oracle Exadata system hardware with RoCE Network Fabric (X8M-2 or later).

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

• You must have an OEDA-generated Engineered System XML configuration file (es.xml) that accurately reflects the current state of the Exadata system.

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

• The environment must be configured with SSH equivalency, so that the OS user and the server running OEDACLI can perform actions as the root user on both the source and target KVM hosts.

• 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 have access to the same Oracle Exadata storage servers.

• The source and target KVM hosts must not have any outstanding work from a previous Exadata Live Update.

• The target KVM host must use Oracle Exadata System Software packages that are the same version as, or newer than, those on the source KVM host.

• 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 being migrated must not have any outstanding work from a previous Exadata Live Update operation that could be applied when the guest restarts during the migration process. Either clear all outstanding work before migration, or reconfigure the guest so that no outstanding work occurs during the migration process.

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

• Additionally, for 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 with Exadata Secure RDMA Fabric Isolation (Secure Fabric) enabled.

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

Syntax

MIGRATE GUEST
     HOSTNAME=guest_name
     MODE={OFFLINE|OFFLINEFORCE|LIVE}
     SRCHOST=source_host
     TGTHOST=target_host
[ WHERE
     STEPNAME=stepname ]

Arguments

• HOSTNAME: Specifies the hostname of the guest being migrated.

• MODE: Specifies the migration mode.

  • OFFLINE: Performs an automated migration process where the guest is gracefully shut down, moved to the target KVM host, and then restarted.

    Use this option in most offline migration situations to gracefully migrate a working guest.

  • OFFLINEFORCE: Performs a forced offline migration process without gracefully shutting down the guest.

    Use this option only in situations where the guest or source KVM host are not accessible. For example, to resurrect a guest from a failed KVM host.

  • LIVE: Performs the migration using Exadata VM Live Migration. In this case, the guest remains available throughout the operation and normal processing is uninterrupted, apart from a brief switchover to the target KVM host.

• SRCHOST: Specifies the hostname or IP address of the source KVM host. This is where the guest resides before the migration operation.

• TGTHOST: Specifies the hostname or IP address of the target KVM host. This is where you intent to move the guest to.

• STEPNAME: Specifies the migration step to perform.

  The following list shows the migration steps (in order) for an offline migration (MODE=OFFLINE or MODE=OFFLINEFORCE).

  1. STOP_GUEST
  2. CREATE_BRIDGES
  3. DETACH_INTERFACES
  4. DETACH_VOLUMES
  5. ATTACH_VOLUMES
  6. MIGRATE_GUEST
  7. ATTACH_INTERFACES
  8. STARTUP_GUEST

  The following list shows the migration steps (in order) for Exadata VM Live Migration (MODE=LIVE).

  1. ATTACH_VOLUMES
  2. CREATE_BRIDGES
  3. MIGRATE_GUEST
  4. DETACH_VOLUMES

  Additionally, you can perform a precheck for Exadata VM Live Migration using the PRECHECK_LIVEMIGRATION step. This step serves as a standalone command that is only performed when the MIGRATE GUEST command uses Exadata VM Live Migration (MODE=LIVE) and includes WHERE STEPNAME=PRECHECK_LIVEMIGRATION.