summaryrefslogtreecommitdiffstats
path: root/docs/requirements/05-implementation.rst
diff options
context:
space:
mode:
authorTomi Juvonen <tomi.juvonen@nokia.com>2015-12-30 10:47:35 +0200
committerTomi Juvonen <tomi.juvonen@nokia.com>2016-01-14 13:29:55 +0200
commita991302e9c0843ad9be8b1bad927dca387283a8c (patch)
tree7e64765b542c4588c1fa61da4d7ee5cbb1ff428f /docs/requirements/05-implementation.rst
parent46e6db1278b8743b10c24ca72280035c0dc625ad (diff)
Support recovering VM on the same host
When a host is failed then the affected VM can be rebooted after the host has been recovered. When a host is going to maintenance the affected VM can be shut down and the booted up on the same host after the maintenance is over. Change-Id: I8ee240eb4d598da6347ae8afee8ce6c6edc07be4 Jira: DOCTOR-9
Diffstat (limited to 'docs/requirements/05-implementation.rst')
-rw-r--r--docs/requirements/05-implementation.rst14
1 files changed, 9 insertions, 5 deletions
diff --git a/docs/requirements/05-implementation.rst b/docs/requirements/05-implementation.rst
index e7f35158..1f1b4a74 100644
--- a/docs/requirements/05-implementation.rst
+++ b/docs/requirements/05-implementation.rst
@@ -296,7 +296,9 @@ described in the previous section applies. In addition, the Controller(s) will
take appropriate actions to evacuate the physical machines in order to prepare
them for the planned maintenance operation. After the physical machines are
emptied, the Controller will inform the Administrator that it can initiate the
-maintenance.
+maintenance. Alternatively the VMs can just be shut down and boot up on the
+same host after maintenance is over. There needs to be policy for administrator
+to know the plan for VMs in maintenance.
Information elements
--------------------
@@ -492,10 +494,12 @@ After reception of this request, the Consumer will decide on the optimal
action to resolve the fault. This includes actions like switching to a hot
standby virtual resource, migration of the fault virtual resource to another
physical machine, termination of the faulty virtual resource and instantiation
-of a new virtual resource in order to provide a new hot standby resource.
-Existing resource management interfaces and messages between the Consumer and
-the VIM can be used for those actions, and there is no need to define additional
-actions on the Fault Management Interface.
+of a new virtual resource in order to provide a new hot standby resource. In
+some use cases the Consumer can leave virtual resources on failed host to be
+booted up again after fault is recovered. Existing resource management
+interfaces and messages between the Consumer and the VIM can be used for those
+actions, and there is no need to define additional actions on the Fault
+Management Interface.
Parameters: