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 |
---|---|
|
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
|
|
Available since MOSK 23.2.
If set to 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
andos_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
andos_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