openstack/nova
Code Issues Proposed changes

docs: add nova host-evacuate command to evacuate documentation

Browse Source 
Split up the evacuate instance documentation into two parts. One
for the existing single instance evacuation and a second new part
for the nova host-evacuate procedure.

Change-Id: Ibcdc2bc3f08e2fab23b9821feae0f489fb64a8f7
Closes-Bug: #1763039
This commit is contained in:
Dominic Schlegel 2018-06-26 10:59:08 +02:00 committed by Eric Fried
parent d9e04c4ff0
commit 7b8e898807
1 changed files with 48 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
doc/source/admin/evacuate.rst
View File

@ -3,15 +3,26 @@ Evacuate instances
==================
If a hardware malfunction or other error causes a cloud compute node to fail,
you can evacuate instances to make them available again. You can optionally
include the target host on the :command:`nova evacuate` command. If you omit
the host, the scheduler chooses the target host.
you can evacuate instances to make them available again.
To preserve user data on the server disk, configure shared storage on the
target host. When you evacuate the instance, Compute detects whether shared
storage is available on the target host. Also, you must validate that the
current VM host is not operational. Otherwise, the evacuation fails.
There are two different ways to evacuate instances from a failed compute
node. The first one using the :command:`nova evacuate` command can be used to
evacuate a single instance from a failed node. In some cases where the node
in question hosted many instances it might be easier to use
:command:`nova host-evacuate` to evacuate them all in one shot.
Evacuate a single instance
~~~~~~~~~~~~~~~~~~~~~~~~~~
The procedure below explains how to evacuate a single instance from a failed
compute node. Please be aware that these steps describe a post failure
scenario and should not be used if the instance is still up and running.
#. To find a host for the evacuated instance, list all hosts:
.. code-block:: console
@ -39,6 +50,9 @@ current VM host is not operational. Otherwise, the evacuation fails.
| adminPass | kRAJpErnT4xZ |
+-----------+--------------+
Optionally you can omit the ``HOST_B`` parameter and let the scheduler
choose a new target host.
#. To preserve the user disk data on the evacuated server, deploy Compute with
a shared file system. To configure your system, see
:ref:`section_configuring-compute-migrations`. The following example does
@ -52,3 +66,34 @@ current VM host is not operational. Otherwise, the evacuation fails.
to specify ``--on-shared-storage`` even if the server is on a
compute host which is using shared storage. The compute service
will automatically detect if it is running on shared storage.
Evacuate all instances
~~~~~~~~~~~~~~~~~~~~~~
The procedure below explains how to evacuate all instances from a failed compute
node. Please note that this method should not be used if the host still has
instances up and running.
#. To find a host for the evacuated instances, list all hosts:
.. code-block:: console
$ openstack host list
#. Evacuate all instances from ``FAILED_HOST`` to ``TARGET_HOST``:
.. code-block:: console
$ nova host-evacuate --target_host TARGET_HOST FAILED_HOST
The option ``--target_host`` is optional and can be omitted to let the
scheduler decide where to place the instances.
The above argument ``FAILED_HOST`` can also be a pattern
to search for instead of an exact hypervisor hostname but it is
recommended to use a fully qualified domain name to make sure no
hypervisor host is getting evacuated by mistake. As long as you are not
using a pattern you might want to use the ``--strict`` flag which got introduced
in version 10.2.0 to make sure nova matches the ``FAILED_HOST``
exactly.