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后要更新数据库。

一、怎样更新？

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

二、power_state命名惯例

取决于ibvirt返回的状态。

废弃的状态：

BLOCKED，本质上应该是RUNNING;

SHUTOFF，如今是SHUTDOWN；

FAILED，如今是NOSTATE。

vm_state

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

一、vm_stae怎样更新

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

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

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

三、vm_state和power_state关系？

两者不是一一映射，表明的侧重点不一样，不能经过推理从一个获得另外一个，因此都是须要的。

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

四、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 （同步电源状态）不鸟正在执行的任务，可能致使奇怪的错误。
五、如何从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。

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

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

二、如何更新？

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是否匹配。

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

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

四、命名变化

最好用动词+”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