Oracle Cloud Infrastructure Documentation

Live, Reboot, and Manual Migration: Moving a Compute Instance to a New Host

This topic provides information about maintenance actions that involve relocating virtual machine (VM) and bare metal instances during infrastructure maintenance events. Available actions include:

Important

For information about when a virtual machine needs to be migrated, see Infrastructure Maintenance.
Tip

Dedicated virtual machine host migration: For information about how to relocate dedicated virtual machine hosts during infrastructure maintenance events, see Managing Maintenance Reboot Migration for Dedicated Virtual Machine Hosts.
Note

Oracle Platform Services: For instances that were created with Oracle Platform Services and located in the compartment ManagedCompartmentForPaaS, you must use the interface for the specific Platform Service to reboot the instances.

Live Migration

Live Migration is a mechanism for moving a VM from one physical server to another while the VM is still running. During a live migration, the source VM instance continues to run as the Compute service copies memory and all virtual components to the new target VM instance. When the copy is complete, there is only a slight pause, typically measured in tens of milliseconds, when the system switches to the new VM.

During an infrastructure maintenance event, Oracle Cloud Infrastructure live migrates supported VM instances from a healthy physical VM host that needs maintenance to a healthy VM host with minimal disruption to running instances.

If an instance cannot be live migrated, Oracle Cloud Infrastructure schedules a due date for reboot migration within 14 to 16 days and sends you a notification. If you do not proactively reboot the instance before the due date, the instance is reboot migrated for you.

By default, Oracle Cloud Infrastructure live migrates the instance without sending any notification about the upcoming maintenance. When a live migration begins and ends, an infrastructure maintenance event is emitted. You can use automation to track infrastructure maintenance events.

Live Migration Support

When you create an instance, select settings that are compatible with live migration. For an existing instance, where supported, you can enable live migration by editing the instance to use settings that are compatible with live migration. Some settings that are incompatible with live migration cannot be edited after you create an instance.

The following table shows the criteria that make an instance compatible with live migration. All criteria must be met for an instance to support live migration.

Category Criteria that support live migration Can setting be edited after creating the instance?
Realm Tenancy is in the commercial realm. No.
Shape

Instance uses one of the following shapes:

  • VM.Standard1 series
  • VM.Standard.A1.Flex
  • VM.Standard.B1 series
  • VM.Standard2 series
  • VM.Standard3.Flex
  • VM.Standard.E2 series
  • VM.Standard.E2.1.Micro
  • VM.Standard.E3.Flex
  • VM.Standard.E4.Flex
  • VM.Standard.E5.Flex
  • VM.Optimized3.Flex

Other VM shapes, bare metal instances, and instances on dedicated virtual machine hosts do not support live migration.

Yes, for some shapes. Change the shape of the instance to a supported shape.

Alternatively, terminate (delete) the instance, but do not delete the associated boot volume. Then, use the boot volume to create a new instance using a shape that supports live migration.
Image

Instances that use Linux or Windows platform images support live migration.

For instances that use custom images or Oracle Cloud Infrastructure Marketplace images, Oracle Cloud Infrastructure attempts to live migrate the instance.

 No.
Networking launch type Instance uses paravirtualized networking. Yes, edit the networking launch type.
Shielded instances Not supported. No.
Windows Defender Credential Guard is enabled Not supported. No.
Virtual network interface cards (VNICs) Maximum total number of attached VNICs is six. Yes, detach and delete secondary VNICs until six or fewer VNICs total are attached.

To determine whether an instance supports live migration:

  1. Open the navigation menu and click Compute. Under Compute, click Instances.
  2. Click the instance that you're interested in.
  3. Check the Live migration field for the instance. If the field displays View incompatibilities, the instance doesn't support live migration.
  4. (Optional) To see which settings are not compatible with live migration, click View incompatibilities.

Reboot Migration

With reboot migration, the instance is stopped, migrated to a healthy host, and restarted. A short downtime occurs during the migration. You can control when the downtime occurs by proactively reboot migrating the instance before the maintenance due date.

Reboot migration is supported for VM instances that use standard, GPU, and dense I/O shapes, and for bare metal instances that use standard shapes. The default maintenance action depends on the instance shape.

  • VM instances:

    • Standard/GPU shapes (including Flex): Within 24 hours after the maintenance due date, the VM instance is stopped, migrated to a healthy host, and restarted. A short downtime occurs during the migration.

      You can control when the downtime occurs by proactively reboot migrating the instance before the maintenance due date.

    • DenseIO shapes (including Flex): On the maintenance due date, the VM instance is stopped, rebuilt, and restarted. A downtime of several hours occurs during the maintenance process.

      If you want to minimize downtime and can delete the locally-attached NVMe-based SSD, you can proactively reboot the instance before the scheduled maintenance time. The instance will be reboot migrated to a healthy host and the SSD will be permanently deleted. A short downtime occurs during the migration.

  • Bare metal instances:

    • Standard shapes: Within 24 hours after the maintenance due date, the bare metal instance is stopped, migrated to a healthy host, and restarted. A short downtime occurs during the migration.

      You can control when the downtime occurs by proactively reboot migrating the instance before the maintenance due date.

      If reboot migration is unsuccessful, Oracle Cloud Infrastructure sends a notification. You must manually migrate the instance to a healthy host.

After the instance is reboot migrated, the Maintenance reboot field is cleared. This change indicates that the instance was moved successfully.

Important

Use the Console, CLI, or SDK to reboot migrate a VM instance. Rebooting the instance from the operating system does not migrate the instance to new hardware.

After a migration, by default the instance is recovered to the same lifecycle state as before the maintenance event. If you have an alternate process to recover the instance after a reboot migration, you can configure the instance to remain stopped after it is migrated to healthy hardware. For more information about configuring migration options, including the lifecycle state of instances after a migration, see Setting Instance Availability During Maintenance Events.

Tip

You can extend the due date for reboot migration, see Extending Maintenance Deadline

Prerequisites for Reboot Migration

Prepare the instance for reboot migration:

  • Ensure that any block volumes defined in /etc/fstab use the recommended options.
  • Ensure that any File Storage service (NFS) mounts use the nofail option.
  • If you use the Oracle-provided script to configure secondary VNICs, ensure it runs automatically at startup.

  • If the instance uses a dense I/O shape, back up the locally-attached NVMe-based SSD:

    1. Create and attach one or more block volumes to the instance.
    2. Copy the data from the NVMe devices to the block volumes.

Moving a VM Instance with Reboot Migration

After you complete the prerequisites:

  1. Stop any running applications.

  2. Use the Console, CLI, or SDK to reboot the instance. Reboot migration is not performed when you restart the instance from the operating system.

    If the instance uses a dense I/O shape:

    • Using the Console: In the Reboot instance dialog box, select the Delete the local NVMe-based SSD and reboot migrate to a healthy host option.
    • Using the CLI or SDK: In the InstanceAction operation, set the allowDenseRebootMigration attribute to true.
    Caution

    For dense I/O instances, the NVMe-based SSD is permanently deleted. We recommend that you create a backup of the SSD before proceeding.
  3. Confirm that the maintenance event in the Maintenance tab is in the Succeeded state. (There are three possible final states: Succeeded, Canceled, Failed).
  4. Start and test any applications on the instance.

  5. For dense I/O instances, if you want to restore the NVMe-based SSD:

    1. Attach the block volumes used to back up local NVMe devices.
    2. Copy the data onto the NVMe storage on the new instance.
    3. Detach and optionally delete the block volumes.

Moving a Bare Metal Instance with Reboot Migration

After you complete the prerequisites:

  1. Stop any running applications.

  2. Use the Console, CLI, or SDK to reboot the instance. Reboot migration is not performed when you restart the instance from the operating system.

    • Using the Console: In the Reboot instance dialog box, select the Reboot migrate the instance to a healthy host option.
    • Using the CLI or SDK: In the InstanceAction operation, pass the value REBOOTMIGRATE as the action to perform. To reboot migrate the instance immediately, leave the timeScheduled attribute empty.
  3. Confirm that the maintenance event in the Maintenance tab is in the Succeeded state. (There are three possible final states: Succeeded, Canceled, Failed).
  4. Start and test any applications on the instance.

Moving an Instance with Manual Migration

For instances without a date in the Maintenance reboot field (available in the Console, CLI, and SDKs), you must move the instance manually. This method requires that you delete (terminate) the instance, and then launch a new instance from the retained boot volume. Instances that have additional VNICs, secondary IP addresses, remote attached block volumes, the Trusted Platform Module (TPM) enabled, or that belong to a backend set of a load balancer require additional steps.

Limitations and Warnings for Manual Migration

Be aware of the following limitations and warnings when performing a manual migration:

  • Any public IP addresses assigned to your instance from a reserved public pool are retained. Any that were not assigned from a reserved public IP address pool will change. Private IP addresses do not change.
  • MAC addresses, CPUIDs, and other unique hardware identifiers do change during the move. If any applications running on the instance use these identifiers for licensing or other purposes, be sure to take note of this information before moving the instance to help you manage the change.
  • Shielded instances have additional limitations. See Migrating Shielded Instances.

Prerequisites for Manual Migration

  1. Before moving the instance, document all critical details:

    • The instance's region, availability domain, and fault domain.
    • The instance's display name.
    • All private IP addresses, names, and subnets. Note that the instance can have multiple VNICs, and each VNIC can have multiple secondary IP addresses.
    • All private DNS names. The instance can have multiple VNICs, and each VNIC can have multiple secondary IP addresses. Each private IP address can have a DNS name.
    • Any public IP addresses assigned from a reserved public pool. Note that the instance can have multiple VNICs, and each VNIC can have multiple secondary private IP addresses. Each VNIC and secondary private IP address can have an attached public IP address.
    • Any block volumes attached to the instance.
    • Any tags on the instance or attached resources.

  2. Prepare the instance for manual migration:

    • Ensure that any block volumes defined in /etc/fstab use the recommended options.
    • Ensure that any File Storage service (NFS) mounts use the nofail option.
    • If you have statically defined any network interfaces belonging to secondary VNICs using their MAC addresses, such as those defined in /etc/sysconfig/network-scripts/ifcfg*, those interfaces will not start due to the change in the MAC address. Remove the static mapping.
    • If you use the Oracle-provided script to configure secondary VNICs, ensure it runs automatically at startup.

Moving an Instance Manually

After you complete the prerequisites, perform the following steps.

  1. Stop any running applications.

  2. Ensure that those applications will not start automatically.

    Caution

    When the relocated instance starts for the first time, any block volumes, secondary VNICs, or any resource that relies on them, will not be attached. The absence of these resources can cause application issues.

  3. If the instance uses a dense I/O shape, back up the locally-attached NVMe-based SSD:

    1. Create and attach one or more block volumes to the instance.
    2. Copy the data from the NVMe devices to the block volumes.
  4. Unmount any block volumes or File Storage service (NFS) mounts.
  5. Back up all block volumes.

  6. Create a backup of the boot volume.

    Important

    Do not generalize or specialize Windows instances.

  7. Terminate (delete) the instance, preserving the attached boot volume:

    Using the Console

    Follow the steps in Terminating an Instance, ensuring that the Permanently delete the attached boot volume check box is cleared. This preserves the boot volume that is associated with the instance.

    Using the API

    Use the TerminateInstance operation and pass the preserveBootVolume parameter set to true in the request.

    Using the CLI

    Use the instance terminate operation and set the preserve-boot-volume option to true.

  8. Create a new instance using the boot volume from the terminated instance.

    (Optional) If the instance is on a new dedicated virtual machine host:

    • In the Placement section, click Show advanced options.
    • For Capacity type, select Dedicated host.
    • Select the dedicated virtual machine host that you want to place the instance on.

    In the create instance flow, specify the private IP address that was attached to the primary VNIC. If the public IP address was assigned from a reserved IP address pool, be sure to assign the same IP address.

  9. When the instance state changes to Running, stop the instance.
  10. Recreate any secondary VNICs and secondary IP addresses.

  11. Attach any block volumes.

    Note

    This step includes any volumes used to back up local NVMe devices. Copy the data onto the NVMe storage on the new instance, and then detach the volumes.
  12. Start the instance.
  13. Start and test any applications on the instance.
  14. Configure the applications to start automatically, as required.
  15. Recreate the required tags.
  16. (Optional) After you confirm that the instance and applications are healthy, you can delete the volume backups.