Instance migration

OpenStack supports the following types of instance migrations:

  • Cold migration (also referred to simply as migration)

    The process involves shutting down the instance, copying its definition and disk, if necessary, to another host, and then starting the instance again on the new host.

    This method disrupts the workload running inside the instance but allows for more reliability and works for most types of instances and consumed resources.

  • Live migration

    The process involves copying the instance definition, memory, and disk, if necessary, to another host while the instance continues running, without shutting it down. The instance then momentarily switches to run on the new host.

    While generally less disruptive to workloads, this method is less reliable and imposes more restrictions on the instance and target host properties to succeed.

Configuring live migration

As a cloud operator, you can configure live migration through the OpenStackDeployment custom resource. The following table provides the details on available configuration.

Parameter

Usage

features:nova:live_migration_interface

Specifies the name of the NIC device on the actual host that will be used by Nova for the live migration of instances.

Mirantis recommends setting up your Kubernetes hosts in such a way that networking is configured identically on all of them, and names of the interfaces serving the same purpose or plugged into the same network are consistent across all physical nodes.

Also, set the option to vhost0 in the following cases:

  • The Neutron service uses Tungsten Fabric.

  • Nova migrates instances through the interface specified by the Neutron tunnel_interface parameter.

features:nova:libvirt:tls

Available since MOSK 23.2. If set to true, enables the live migration over TLS:

spec:
  features:
    nova:
      libvirt:
        tls:
          enabled: true

See also Encryption of live migration data.

Allowing non-administrative users to migrate instances

Available since MOSK 24.3

MOSK provides the following distinct sets of policies that govern access to cold and live migrations:

  • os_compute_api:os-migrate-server:migrate and os_compute_api:os-migrate-server:migrate_live define the ability to initiate migrations without specifying the target host. In this case, the OpenStack Compute scheduler selects the best suited target host automatically.

  • os_compute_api:os-migrate-server:migrate:host and os_compute_api:os-migrate-server:migrate_live:host define the ability to initiate migration together with specifying the target host. Depending on the API microversion used to start the migration, the host is either validated by the scheduler (recommended) or forced regardless of other considerations. The latter option is not recommended as it may lead to inconsistencies in the internal state of the Compute service.

Since MOSK 24.3, the default policies for migrations without the target host specification is set to rule: project_member_or_admin. This means that migration is available to both cloud administrators and project users with the member role.

The migration to a specific host requires administrative privileges.

Revert to admin-only migrations

If the default policy does not suit your deployment, you can require administrative access for all instance migrations by setting these policy values to rule:context_is_admin, or any other value appropriate for your use case.

If you use the default policies and want to revert to the old defaults, ensure that the following snippet is present in your OpenStackDeployment custom resource:

kind: OpenStackDeployment
spec:
  features:
    policies:
      nova:
        os_compute_api:os-migrate-server:migrate: rule:context_is_admin
        os_compute_api:os-migrate-server:migrate_live: rule:context_is_admin