Masakari  provides Virtual Machine High Availability (VMHA) service for
OpenStack clouds by automatically recovering the KVM-based Virtual Machine(VM)s
from failure events such as VM process down, provisioning process down, and
nova-compute host failure. It also provides API service to manage and control
the automated rescue mechanism.
Masakari use cases:
1. Allow evacuation of an instance which is in resized state.
2. If instance was in stopped state before resizing then after evacuation it
should remain in stopped state instead of active state.
Problem from Nova:
Nova does not allow evacuation of an instance which is in resized state.
Implementation in masakari:
In masakari, we are setting an instance to an error state if the vmstate is
resized before evacuating it to a new host. Once an instance (which was in
resized state) is evacuated then it becomes active on the new host. The main
problem with this implementation from user's point of view is the instance goes
into active state after evacuation, it should be in stopped state if the prior
action on the instance before resizing was stop. In masakari, It's possible to
set the vm state to stopped state after evacuation but for a short period the
instance will go into the active state which is unacceptable.
Proposing changes to Nova:
In the current nova code, if the instance is in stopped state before
evacuation, then it remains in the stopped state after evacuation is complete.
On the similar lines, we are proposing nova should allow instance to be
evacuated in resized state and after evacuation the instance should remain in
stopped state if the prior action on the instance is stopped before resizing.
If the vmstate is resized, the old vmstate in instance_systemmetadata will be
either active/stop. Based on this old vmstate, nova compute can decide whether
to set the vm state to active or stopped during evacuation.
Please let me know your opinion about allowing evacuation of instances in
resized state in nova.
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
OpenStack Development Mailing List (not for usage questions)