背景介绍：
系统运行过程中，经常会遇到虚拟机异常退出，或者虚拟机所在物理主机异常下电的情况出现。当这些管理人员不可预知的异常情况出现后，管理员可能会希望系统能够自动的恢复，把异常下电的虚拟机给启动起来，把异常下电的物理主机上面的虚拟机给在其他健康的物理节点上面启动起来。达到虚拟机高可用的目的。
我们按物理主机能否正常工作把高可用性分成下面两类来进行描述


物理主机仍然健康时的虚拟机自愈
物理主机仍然健康，采取的高可用策略比较简单，就是尽力的把虚拟机在源节点上启动起来。我们把这种动作叫做自愈。
细分为下面几种场景：


2.1 物理主机健康，仅仅是把物理主机重启了一下
这种场景下可以有两种处理策略：
a. 物理主机重新上电后，这个物理主机上面的原有运行的虚拟机，系统不给自动上电；
b. 物理主机重新上电后，这个物理主机上面的原有运行的虚拟机，系统给自动上电。
通过如下配置完成上面策略的切换：
resume_guests_state_on_host_boot，配置为True则系统自动把虚拟机上电满足上面的场景b；
配置为False，不自动上电，满足上面场景a。
这个配置项是按计算节点配置的，不同的计算节点可以采用不同的策略。修改配置后，需要重启对应计算节点的 nova-compute服务。


2.2 物理主机健康，虚拟机异常下电了
  虚拟机异常下电的定义：不是通过openstack提供的虚拟机操作命令，而虚拟机处于了下电状态，比如虚拟机内部异常导致虚拟机下电，通过libvirt命令直接把虚拟机关机等。
  这种状态的虚拟机有两种处理策略：
  A. 执行虚拟机下电动作，让数据库记录的状态真实反应虚拟机状态，这样数据库和底层虚拟化层看到的虚拟机都是下电状态的了，即以虚拟机真实状态同步数据库；
    B. 执行虚拟机上电动作，让虚拟机的真实状态和数据库中记录的状态一致，使数据库和虚拟机的真实状态都为运行态，即以openstack的数据库中状态同步虚拟机的真实状态。
  上面的两个策略通过配置项来选择，heal_instance_customed:
取值为False，表示按上面的A执行，以虚拟机的真实状态为准；
设置为True，表示上面的B，以数据库中的状态为准。


 监控原理：数据库中维护的虚拟机状态和实际虚拟化层看到的状态比较，目前仅仅处理了数据库是active状态，而实际运行态为shutoff的虚拟机。
 针对上面的第二种处理策略，为了满足应标测试，加入了本地试图上电一定次数扔不能上电成功后，尝试在其他主机上面上电的功能，于是针对B又增加了下面的策略：本地自愈、本地+异地自愈、异地自愈（异地自愈采用的就是冷迁移的动作）。通过配置项heal_instance_policy来配置，可取值为local/remote/=local-remote：3（3为默认本地尝试次数，也可由用户指定）,详细描述参加 http://dev.zte.com.cn/topic/view/9046


物理主机宕机状态下虚拟机异地重生
系统通过带外管理工具，判断物理主机的电源状态，如果物理主机电源状态为下电态且物理主机上面有运行的虚拟机，则把这些虚拟机在其他的计算节点上面进行重新部署。由于源物理主机已经宕机，没法拷贝源主机上面保存的数据信息，所以本功能仅支持采用共享存储的虚拟机（即仅支持云盘起的虚机）。
本功能默认关闭，开启这个功能可以通过修改配置项 monitor_evacuate_on_offnode_chk_interval 来指定一个检测周期。默认功能关闭的。详细介绍请参考 http://dev.zte.com.cn/topic/view/9044






总结：
1.host正常，host重启：
host重新上电后虚机是否自动上电，该策略由resume_guests_state_on_host_boot配置项决定：
配置为True时，虚机自动上电；
配置为False时，虚机不自动上电。
resume_guests_state_on_host_boot配置项按计算节点配置，配置后需重启nova-compute服务。


2.host正常，虚机异常下电：
虚机异常下电后，数据库中的状态与虚机的实际状态不一致。有两种解决策略：
以虚机真实的状态同步数据库：heal_instance_customed=false
以虚机数据库中的状态同步真实状态：heal_instance_customed=true


3.host宕机，虚机在运行：
将宕机的host上的运行的主机在其他host上重新部署：monitor_evacuate_on_offnode_chk_interval