Openstack VMState

目录
[隐藏]
1 Nova state machine simplification
1.1 power_state
1.2 vm_state
1.3 task_state
Nova state machine simplification
There are vm_states, task_states, and power_states for each VM. The use of them is complicated. Some states are confusing, and sometimes ambiguous. There also lacks a guideline to extend/add new state. This proposal aims to simplify things, explain and define precisely what they mean, and why we need them. A new user-friendly behavior of deleting a VM is also discussed.

A TL;DR summary:

power_state is the hypervisor state, loaded “bottom-up” from compute worker;
vm_state reflects the stable state based on API calls, matching user expectation, revised “top-down” within API implementation.
task_state reflects the transition state introduced by in-progress API calls.
“hard” delete of a VM should always succeed as long as the DB is available.
power_state and vm_state may conflict with each other, which needs to be resolved case-by-case.
power_state
power_state should be the state we get by calling virt driver on a particular VM. The actual state lives in the hypervisor is always authoritative, and the power_state in the db should be viewed as a snapshot of the state in the (recent) past. It can be periodically updated, and should also be updated at the end of a task if the task is supposed to affect power_state.

How is it updated?
Always “bottom-up”: reported by a compute worker, override the field in DB. The update may trigger a “reconcile” procedure against vm_state. see below.
Naming convention
will stick to the existing ones derived from libvirt.
obsolete state: BLOCKED, which is essentially RUNNING; SHUTOFF, which is mapped to SHUTDOWN; FAILED, which is mapped to NOSTATE.
vm_state
vm_state should describe a VM’s current stable (not transition) state. That is, if there is no ongoing compute API calls (running tasks), vm_state should reflect what the customer expect the VM to be. A good example of vm_state: ACTIVE, meaning the VM is running normally. A bad example of vm_state SUSPENDING – It’s a transition state, meaning that the VM is in the process of suspending and could become to suspended in any seconds. A transition state belongs to task_state.

How is it updated?
vm_state should only be updated at the end of a task, when the task successfully finishes, and setting the task_state to None. Without API calls, the vm_state should never change. If a task fails, but is properly cleaned up (e.g. live migration fails, but the VM is working fine on the source node from rollback), the vm_state should not change. If the task fails and is not possible to rollback, the vm_state is set to ERROR.
Naming convention: an adjective for vm_state.
What is the relationship with power_state?
There is no one-to-one mapping. They represent slightly different information. You cannot infer from one to another and need both. For example, after you rescue a VM, the VM is running with the rescue image. The power_state could be either RUNNING, or BLOCKED. But vm_state should only be RESCUED. Based on power_state alone, you can’t tell the whether to use ACTIVE or RESCUED.
When power_state and vm_state disagree, how to reconcile?
“First, when there is an ongoing task, the vm_state and power_state may, and probably will disagree. This is because vm_state only represents stable state. During a task execution, the state is in transitioning and is stale.
When there is no task in progress, power_state and vm_state should agree unless errors or failures happen. In those cases, it must be reconciled case by case. For example:
if power_state=SHUTOFF, but vm_state=ACTIVE, it is very likely because the shutdown command is issued inside the VM. So the power_state is accurate. This is roughly equivalent to an implicit stop() API call. vm_state should be revised to STOPPED.
If power_state=BLOCKED, vm_state=HARD_DELETED, that means the user has already asked to delete the VM but somehow the process failed. We should try to delete again.
if power_state=BLOCKED, but vm_state=PAUSED, that means there was probably some unexpected problem during the pause() virt driver call before. FIXME: what’s the most user-friendly behavior in this case? set to ERROR?
(right now _sync_power_states do not respect ongoing tasks and may lead to weird behavior)
How do I get EC2 equivalent state from vm_state?
ec2 state contains both stable (e.g. running) and transition state (e.g. pending, shutting-down). You’ll need task_state together with vm_state to deduce ec2 state.
vm_state after cleanup:
INITIALIZED: VM is just created in the database, but has not been built. (was BUILDING)
ACTIVE: VM is running with the specified image.
RESCUED: VM is running with the rescue image.
PAUSED: VM is paused with the specified image.
SUSPENDED: VM is suspended with the specified image, with a valid memory snapshot.
STOPPED: VM is not running, and the image is on disk.
SOFT_DELETED: VM is no longer running on compute, but the disk image remains and can be brought back.
HARD_DELETED: From quota and billing’s perspective, the VM no longer exists. VM will eventually be destroyed running on compute, disk images too.
RESIZED: The VM is stopped on the source node but running on the destination node. The VM images exist at two locations (src and dest, with different sizes). The user is expected to confirm the resize or revert it. (the same functionality of the old task_state.RESIZE_VERIFY)
ERROR: some unrecoverable error happened. Only delete is allowed to be called on the VM.
the obsolete state: REBUILDING, MIGRATING, RESIZING should all be with task_state.
SHUTOFF should also be gone. It’s a state that’s very confusing, and should be matched to STOPPED or DELETED based on shutdown_terminate flag.
task_state
task_state should represent a transition state, and is precisely associated with one compute API, indicating which task the VM is currently running. The exact task_state should not be needed to determine whether a task is allowed on the vm_state state machine. Only the fact that whether a task‘s progress is needed.

Special task: force_delete (or hard delete)
Deleting VMs should always be allowed, and it should always succeed. The user should have freed more resources in her quota and no longer be billed. Unfortunately, it might be the case that a previous task is stuck so that task_state is never going back to None, or the virt driver gets stuck to destroy the VM, or the compute node is not available due to network/hardware issues to execute the destroy. So, we should not wait until the force_delete() task to reach to compute worker then update vm_state to HARD_DELETED. Instead, vm_state should be updated immediately without going through compute workers.In other words, the force_delete() task works as a pure database operation. The actual cleanup is immediately followed, but is no different than a reconcile procedure between the power_state and vm_state, which can also be triggered periodically.
How is it updated?
task_state can be set when the task is certain that it is the only running task on the VM. To make the update atomic, a unique task_id (uuid format) must be generated in the beginning and be associated with the VM id. If the VM already has a task_id, it means another task is in progress. During the task execution, task_id is propagated via the RequestContext data structure to workers. To update task_state in the middle of a task (e.g. to report task progress), one must make sure that the task_id of the VM matches the current task_id. Otherwise, the current running task is preempted by another task (right now only possible by a force_delete task). When a task finishes, the task_state is set to None, and the task_id is set to None too.
Alternatively since hard delete is the only one that can preempt other tasks, we probably do not need to add task_id right now. But we would need to check vm_state to see it’s not HARD_DELETED instead of checking if task_id matches.
Do we really need to separate vm_state and task_state?
Technically, vm_state (stable) and task_state (transition) are disjoint and you could combine them together. The biggest benefit of separation is that the state transition diagram is much simpler – you only need to think about a DFA between the stable vm_state. The space is much smaller. If a certain extension needs a new task_state, the state transition diagram stays untouched.
Naming convention
A verb + “ing” is preferred to describe the task_state where the verb is the compute API method. During the task execution, the task_state should never change. To express the progress of the task, a separate field should be used instead to simplify state machine.
None: no task is currently in progress
BUILDING
IMAGE_SNAPSHOTTING
IMAGE_BACKINGUP
UPDATING_PASSWORD
PAUSING
UNPAUSING
SUSPENDING
RESUMING
DELETING
STOPPING
STARTING
RESCUING
UNRESCUING
REBOOTING
REBUILDING
POWERING_ON
POWERING_OFF
RESIZING
RESIZE_REVERTING
RESIZE_CONFIRMING
SCHEDULING
BLOCK_DEVICE_MAPPING
NETWORKING
SPAWNING
RESIZE_PREP
RESIZE_MIGRATING
RESIZE_MIGRATED
RESIZE_FINISH
obsolete:
RESIZE_VERIFY is not a transition state, but a stable state. It’s the new RESIZED state in vm_state now.

原文：https://wiki.openstack.org/wiki/VMState

Create Instance States
The following diagram shows the sequence of VM states, task states, and power states when a new VM instance is created.

Allowed State Transitions¶

原文：http://docs.openstack.org/developer/nova/vmstates.html#preconditions-for-commands

OpenStack虚拟机状态

OpenStack创建一个虚拟机，涉及到三种状态，vm_state，task_state和power_state。

先总结几点：

电源状态(power_state)：是hypervisor的状态，从计算节点”由下而上“加载。
虚拟机状态(vm_state)：反应基于API调用的一种稳定状态，符合用户体验，从上而下的API实现。
任务状态(task_state)：代表API调用过程的过渡状态。
只要数据库可用，就可以强删虚拟机。（”hard“ delete of VM）
电源状态和虚拟机状态会彼此冲突，需具体情况具体分析。
Power_state
Power_state是我们调用虚拟机中驱动获得的一个状态，事实上hypervisor的状态才是权威的。数据库中power_state只是之前状态的一个快照，

会被周期性更新，并且在有任务改变了power_state后要更新数据库。

1、怎样更新？

通常是”自下而上“，由计算节点产生，重写数据库。这个更新过程可能引起和vm_state的一致性冲突，如下。

2、power_state命名惯例

取决于ibvirt返回的状态。

废弃的状态：

BLOCKED，本质上应该是RUNNING;

SHUTOFF，现在是SHUTDOWN；

FAILED，现在是NOSTATE。

vm_state
vm_sate描述虚拟机当前稳定状态，而非过渡状态。如果没有running_tasks，虚拟机就应该是用户期待的状态，比如active。ACTIVE是一个vm_state，因为它代表虚拟机正常运行；而SUSPENDING是一个过渡状态，代表n秒后虚拟机将被挂起，所以应该属于task_state。

1、vm_stae怎样更新

vm_state仅在任务结束后更新，即当一个任务成功结束并且设置task_state状态为None。

当有API调用时，vm_state永远不能改变。如果任务失败，并且合适的清理后（比如live迁移失败，任务回滚，虚拟机在源节点正常运行），虚拟机状态不变。如果任务失败并且不能回滚，vm_state状态被置为ERROR。

2、vm_state命名惯例：使用一个形容词

3、vm_state和power_state关系？

二者不是一一映射，代表的侧重点不同，不能通过推理从一个得到另一个，所以都是需要的。

比如，当你去修复一个虚拟机，虚拟机从一个rescue镜像启动，此时power_state状态为RUNNING，但是vm_state状态只能是RESCUED。单单靠power_state是不能确定vm_state是ACTIVE还是RESCUED。

4、power_state和vm_state状态不一致，如何修正？

首先，有正在运行的任务时，vm_state和power_state极有可能不同，因为vm_state代表一个稳定状态，在任务运行期间，状态是过度状态，vm_state本来就是过期的。

当没有任务运行时，power_state和vm_state应该保持一致，除非出错或者失败，这种情况，要具体分析。

a、如果power_state=SHUTOFF，但是vm_state=ACTIVE，极有可能是虚拟机内部shotdown命令出错，所以power_state正确。一个粗暴但等价的方法，手动调用一个内部方法stop()API，虚拟机应该被修正为STOPPED。

b、如果power_state=BLOCKED，vm_state=HARD_DELETED，代表用户已经要求删除虚拟机但是过程失败了。所以尝试再次删除。

c、如果power_state=BLOCKED，vm_state=PAUSED，代表可能是pause()方法调用前出了不可预料的问题。此时修正方法就看怎样对用户最友好了，maybe设置vm_state为ERROR。

到此，会发现 _sync_power_states （同步电源状态）不鸟正在执行的任务，可能导致奇怪的错误。
5、如何从vm_state中获得和EC2等价的状态？

ec2状态包含稳定状态和过渡状态。所以需要同时根据task_state和vm_state来推断ec2状态。

vm_state如下：

INITIALIZED：虚拟机仅仅在数据库创建（应该是说表结构建好了），但是还没开始创建。（状态是BUILDING）
ACTIVE:虚拟机正在运行，使用特定的镜像。
RESCUED：虚拟机正在运行，但使用rescue镜像。
PAUSED：虚拟机暂停，使用特定镜像。依然占用计算和内存资源。
SUSPENDED：虚拟机挂起，使用的是特定的镜像，但是不占用计算和内存资源。
STOPPED：虚拟机停止，但是镜像依然在磁盘上。
SOFT_DELETED:虚拟机不再计算节点运行了，但是磁盘镜像依然保存，可以恢复。
HARD_DELETED:从配额和计费角度看，虚拟机不存在了。最终虚拟机和磁盘被销毁。
RESIZED：虚拟机在源节点停止，在目标节点运行。虚拟机镜像在源节点和目标节点都有，但是参数不同。用于需要确认resize(调整参数)或者恢复虚拟机。（废弃的的task_state RESIZE_VERIFY和vm_state RESIZED功能一样。）
ERROR：发生了无法恢复的错误，唯一的可执行的操作就是删除虚拟机。
vm_state中废弃的状态REBUILDING，MIGRATING，RESIZING都放在了task_state中。而SHUTOFF不用了，因为这个状态很费解，应该根据shutdown_terminate标记被划分到STOPPED或者DELETED。

task_state
task_state代表过渡状态，和一个computeAPI紧密相关，表明虚拟机当前执行哪个任务。处于vm_state的虚拟机是不会有task_state，只有正在运行的进程有task_state。

1、特定任务：force_delete(或者hard delete)

虚拟机什么时候都能成功删除。用户删除虚拟机可以释放配额里更多资源，不再被收费。不幸的是，可能出现这种情况，一个前置任务卡住了所以task_state永远不能到None，或者虚拟驱动在销毁虚拟机时卡住了，再或者计算节点因为网络/硬件的原因不可用而无法执行销毁虚拟机操作。所以，不应该等到force_delete() 任务获得计算节点然后更新虚拟机状态为HARD_DELETED。而应该是说，vm_state立马更新而不去检查计算节点。换句话说，force_delete() 任务是一个纯粹的数据库操作。一些善后工作（真正的清除工作）随后进行，也不需要power_state和vm_state之间的一致性操作，因为它们会被定期触发。

2、如何更新？

task_state被设置当确认它是虚拟机上唯一执行的任务时。要做到原子更新，任务开始会生成一个独一无二的task_id(uuid格式)和虚拟机id关联。如果虚拟机已经有一个VM id，说明已经有别的任务在运行。在任务执行过程中，task_id通过RequestContext数据格式传播。在任务执行中途如果要更新ask_state，必须确认虚拟机的task_id匹配当前执行任务的id，否则新任务抢占当前任务（目前只有force_delete）。当任务成，task_state置为None，同时task_id置为None。

因为hard delete是唯一一个可以抢占其他任务的任务，我们没必要立即设置task_id，但是需要检查vm_state以确认它不是HARD_DELETE而不是去检查task_id是否匹配。

3、真的要分开vm_state和task_state吗？

从技术上讲,虚拟机状态(稳定)和任务状态(过渡)没有交集，可以组合使用。分开最大的好处就是状态转换图简单得多——只要考虑vm_state之间的DFA。如果需要增加一个新task_state,状态转换图保持不变。

4、命名变化

最好用动词+”ing“来描述task_state，且这个动词是compute API方法。任务执行期间，task_state不变。要表述任务的进展,应该使用一个单独的领域,而不是简化状态机。

None:没有正在执行的任务
BUDILDING
IMAGE_SNAPSHOTTING
IMAGE_BACKINGUP
UPDATING_PASSWORD
PAUSING
UNPAUSING
SUSPENDING
RESUMING
DELETING
STOPPING
STARTING
RESCUING
UNRESCUING
REBOOTING
REBUILDING
POWERING_ON
POWERING_OFF
RESIZING
RESIZE_REVERTING
RESIZE_CONFIRMING
SCHEDULING
BLOCK_DEVICE_MAPPING
NETWORKING
SPAWNING
RESIZE_PREP
RESIZE_MIGRATING
RESIZE_MIGRATED
RESIZE_FINISH
废弃的状态：
RESIZE_VERIFY不是一个过渡状态，而是稳定状态。变成了vm_state中的新状态RESIZED。

原文：http://www.cnblogs.com/starof/p/4221270.html?utm_source=tuicool&utm_medium=referral

openstack学习笔记一 虚拟机启动过程代码跟踪
原文：http://blog.csdn.net/xiaobei4929/article/details/40786701

openstack Kilo Nova中的系统状态分析：
http://www.aboutyun.com/thread-13060-1-1.html