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。

参考：

https://wiki.openstack.org/wiki/VMState

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