1、 nova-compute 在计算节点上运行，负责管理节点上的 instance。
OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。
nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。
———————————————————————————————————————————————————————————————————————————
2、nova-compute 的功能可以分为两类：
- 定时向 OpenStack 报告计算节点的状态（通过hypervisor来获取主机资源信息）
- 实现 instance 生命周期的管理·
3、虚拟机创建
nova-compute 创建 instance 的过程可以分为 4 步：
- 为 instance 准备资源（根据规格flavor准备内存，cpu，硬盘等）
- 创建 instance 的镜像文件（通过glance下载image并创建instance的镜像文件）
- 创建 instance 的 XML 定义文件
- 创建虚拟网络并启动虚拟机
——————————————————————————————————————————————————————————————————————————
4、日志查看：
每个操作都被分配唯一的Request ID，且夸文件
OpenStack 的日志格式都是统一的，如下
<时间戳><日志等级><代码模块><RequestID><日志内容><源代码位置>
简单说明一下
时间戳 日志记录的时间，包括 年 月 日 时 分 秒 毫秒
日志等级 有INFO WARNING ERRORDEBUG等
代码模块 当前运行的模块Request ID 日志会记录连续不同的操作，为了便于区分和增加可读性，每个操作都被分配唯一的Request ID,便于查找
日志内容 这是日志的主体，记录当前正在执行的操作和结果等重要信息
源代码位置日志代码的位置，包括方法名称，源代码文件的目录位置和行号。这一项不是所有日志都有
下面举例说明
2015-12-10 20:46:49.566 DEBUG nova.virt.libvirt.config [req-5c973fff-e9ba-4317-bfd9-76678cc96584None None] Generated XML(‘<cpu>\n <arch>x86_64</arch>\n <model>Westmere</model>\n <vendor>Intel</vendor>\n <topologysockets="2" cores="3" threads="1"/>\n <featurename="avx"/>\n <feature name="ds"/>\n <feature name="ht"/>\n <featurename="hypervisor"/>\n <featurename="osxsave"/>\n <featurename="pclmuldq"/>\n <featurename="rdtscp"/>\n <feature name="ss"/>\n <feature name="vme"/>\n <featurename="xsave"/>\n</cpu>\n‘,) to_xml/opt/stack/nova/nova/virt/libvirt/config.py:82
这条日志我们可以得知：
- 代码模块是 nova.virt.libvirt.config，由此可知应该是 Hypervisor Libvirt 相关的操作
- 日志内容是生成 XML
- 如果要跟踪源代码，可以到 /opt/stack/nova/nova/virt/libvirt/config.py 的 82 行，方法是 to_xml
5、Suspend 和 Pause 操作做个比较：
相同点
两者都是暂停 instance 的运行，并保存当前状态，之后可以通过 Resume 操作恢复
不同点
1. Suspend 将 instance 的状态保存在磁盘上；Pause 是保存在内存中，所以 Resume 被 Pause的 instance 要比 Suspend 快。
2. Suspend 之后的 instance，其状态是 Shut Down；而被 Pause 的 instance 状态是Paused。
3. 虽然都是通过 Resume 操作恢复，Pause 对应的 Resume 在OpenStack 内部被叫作 “Unpause”；Suspend对应的 Resume 才是真正的 “Resume”。这个在日志中能体现出来。
6、Nova 虚拟机快照（snapshot）
暂停Instance à对Instance的镜像文件创建快照à恢复Instanceà将快照（snapshot）上传到Glance上
7、恢复故障虚拟机（Rebuild Instance）
RebuildInstance 会用snapshot替换Instance当前的镜像文件，并且保持该Instance的其他资源属性不变
流程：
Rebuild请求à关闭当前Instanceà下载新的Image，并准备Instance的镜像文件 à启动Instance
8、Instance shelve（释放占用的资源）
Instance 被 Suspend 后虽然处于 Shut Down 状态，但 Hypervisor 依然在宿主机上为其预留了资源，以便在以后能够成功 Resume。
如果希望释放这些预留资源，可以使用 Shelve 操作。Shelve 会将 instance 作为 image 保存到 Glance 中，然后在宿主机上删除该 instance。
流程：
接收shelve消息à关闭instanceà对Instance 执行snapshot操作，成功后将snapshot生成的image保存到glance上，命名为<instance name>-shelvedà最后删除 instance 在宿主机上的资源à暂停操作成功执行后，instance 的状态变为 Shelved Offloaded，电源状态是 Shut Down
—————————————————————————————————————————————————————————————————————————————————————
9、Unshelve （相当于用snapshot快照生成的image去重新创建一个与原来的instance一样的虚拟机，故流程与launch instance时一直的)
因为 Glance 中保存了 instance 的 image，unshelve 的过程其实就是通过该 image launch 一个新的 instance，nova-scheduler 也会调度合适的计算节点来创建该 instance。
instance unshelve 后可能运行在与 shelve 之前不同的计算节点上，但 instance 的其他属性（比如 flavor，IP 等）不会改变。
10、Migrate 虚拟机迁移
迁移schedule时防止选择源主机的机制：nova-compute 在做 migrate 的时候会检查目标节点，如果发现目标节点与源节点相同，会抛出 UnableToMigrateToSelf 异常。Nova-compute 失败之后，scheduler 会重新调度，由于有 RetryFilter，会将之前选择的源节点过滤掉，这样就能选到不同的计算节点了。
总体思路：
nova-scheduler 发送消息，通知计算节点可以迁移instance 了ànova-compute 执行操作 à源节点的instacne关闭，将instance的镜像文件上传到目的主机
详细流程：
nova-compute 首先会尝试通过 ssh 在目标节点上的 instance 目录里 touch 一个临时文件，如果 touch 失败，说明目标节点上还没有该 instance 的目录，也就是说，源节点和目标节点没有共享存储。那么接下来就要在目标节点上创建 instance 的目录à关闭 instanceà将 instance 的镜像文件通过 scp 传到目标节点上à在目标节点上启动 instance(类似launch)
注：ssh 和scp需要密码验证，各个计算节点之间需要无密码连接，因为后台无法输入密码
11、虚拟机热迁移（Live Migrate）：
a、基于共享存储的虚拟机热迁移（instance的镜像文件不需要迁移，只需要将instance的状态迁移到目标节点）
b、基于本地存储的整机热迁移(block Migrate：instance在迁移的时候需要将其镜像文件从源节点传到目标节点)
虚拟机block Migrate
源和目标节点的CPU类型需要一致。
源和目标节点的Libvirt版本要一致。
块迁移（block Migrate）目前只支持vfat类型的config driver 所以在nova-compute.conf中指定config_drive_format=vfat
具体流程：
Api接收消息(live_migrate)à目标节点执行迁移前的准备工作（首先将instance的数据迁移过来，包括镜像文件，虚拟机网络，内存等资源，目标节点会创建Instance目录）à源节点暂停Instance à在目标节点上Resume instance à在源节点上执行迁移后的处理工作，删除instance à在目标节点上创建XML文件，在hyphervisor中定义instance 使之下次可以正常启动。
共享存储迁移：
流程：
1、instance在迁移的时候需要将其镜像文件从元节点传到目标节点
12、虚拟机系统挂了（rescue）
流程：
Nova rescue 虚拟机名 (默认使用当前instance的image) à使用image创建引导盘 disk.rescue à启动虚拟机 à使用virsh edit 虚拟机名 修改disk.rescue为vda 真正的启动盘修改为vdb
13、计算节点宕机，nova-compute进程已经挂掉
Rebuild 可以恢复损坏的 instance。
那如果是宿主机坏了怎么办呢？ 比如硬件故障或者断电造成整台计算节点无法工作，该节点上运行的 instance 如何恢复呢？
用 Shelve 或者 Migrate 可不可以？ 很不幸，这两个操作都要求 instance 所在计算节点的 nova-compute 服务正常运行。幸运的是，还有 Evacuate 操作。
Evacuate可在 nova-compute 无法工作的情况下将节点上的instance 迁移到其他计算节点上。但有个前提： Instance 的镜像文件必须放在共享存储上。
流程：（只能在后台执行）
执行命令nova evacuate 主机名--no-shared-storage à消息下发到nova-api ànova-schedule筛选好主机 ànova-compute分配资源，使用共享存储上的镜像文件à启动instance