diff options
author | Rajesh Tailor <ratailor@redhat.com> | 2022-06-18 17:00:47 +0530 |
---|---|---|
committer | Rajesh Tailor <ratailor@redhat.com> | 2022-09-23 09:06:58 +0530 |
commit | b65a910834c04a3fd777ef9db7e012f44797ba30 (patch) | |
tree | aae9cfd07d3e06c1885a6f9536cb647f65d32ada | |
parent | 13c1450febdd3ad326e8e1cd07156988393d1532 (diff) | |
download | nova-b65a910834c04a3fd777ef9db7e012f44797ba30.tar.gz |
Update Availability zone doc page
Availability zone doc page [1] mentioned that server moving
operation (evacuate/live-migrate) request can force target host
and bypass scheduler.
This support of forcing target host for evacuate/live-migrate
request was removed in [2].
This change updates the doc page by mentioning that it was possible
to force a host with older API microversion and how to use it, if
user wants to force target host for evacuate/live-migrate.
[1] https://docs.openstack.org/nova/latest/admin/availability-zones.html#implications-for-moving-servers
[2] https://review.opendev.org/q/topic:bp%252Fremove-force-flag-from-live-migrate-and-evacuate
Closes-Bug: #1947421
Change-Id: Iaf989ccbde49a8c3735d260b2dd4a319bc77caf8
-rw-r--r-- | doc/source/admin/availability-zones.rst | 56 |
1 files changed, 41 insertions, 15 deletions
diff --git a/doc/source/admin/availability-zones.rst b/doc/source/admin/availability-zones.rst index ffe1be06f9..aff8a0ab31 100644 --- a/doc/source/admin/availability-zones.rst +++ b/doc/source/admin/availability-zones.rst @@ -118,11 +118,47 @@ Implications for moving servers There are several ways to move a server to another host: evacuate, resize, cold migrate, live migrate, and unshelve. Move operations typically go through -the scheduler to pick the target host *unless* a target host is specified and -the request forces the server to that host by bypassing the scheduler. Only -evacuate and live migrate can forcefully bypass the scheduler and move a -server to a specified host and even then it is highly recommended to *not* -force and bypass the scheduler. +the scheduler to pick the target host. + +Prior to API microversion 2.68, using older openstackclient (pre-5.5.0) and +novaclient, it was possible to specify a target host and the request forces +the server to that host by bypassing the scheduler. Only evacuate and live +migrate can forcefully bypass the scheduler and move a server to specified host +and even then it is highly recommended to *not* force and bypass a scheduler. + +- live migrate with force host (works with older openstackclients(pre-5.5.0): + +.. code-block:: console + + $ openstack server migrate --live <host> <server> + +- live migrate without forcing: + +.. code-block:: console + + $ openstack server migrate --live-migration --host <host> <server> + +While support for 'server evacuate' command to openstackclient was added +in 5.5.3 and there it never exposed ability to force an evacuation, but +it was previously possible with novaclient. + +- evacuate with force host: + +.. code-block:: console + + $ nova evacuate --force <server> <host> + +- evacuate without forcing using novaclient: + +.. code-block:: console + + $ nova evacuate + +- evacuate without forcing using openstackclient: + +.. code-block:: console + + $ openstack server evacuate --host <host> <server> With respect to availability zones, a server is restricted to a zone if: @@ -150,16 +186,6 @@ If the server was not created in a specific zone then it is free to be moved to other zones, i.e. the :ref:`AvailabilityZoneFilter <AvailabilityZoneFilter>` is a no-op. -Knowing this, it is dangerous to force a server to another host with evacuate -or live migrate if the server is restricted to a zone and is then forced to -move to a host in another zone, because that will create an inconsistency in -the internal tracking of where that server should live and may require manually -updating the database for that server. For example, if a user creates a server -in zone A and then the admin force live migrates the server to zone B, and then -the user resizes the server, the scheduler will try to move it back to zone A -which may or may not work, e.g. if the admin deleted or renamed zone A in the -interim. - Resource affinity ~~~~~~~~~~~~~~~~~ |