1、       nova-compute 在计算节点上运行，负责管理节点上的 instance。

OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。

nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

———————————————————————————————————————————————————————————————————————————

2、nova-compute 的功能可以分为两类：

1. 定时向 OpenStack 报告计算节点的状态（通过hypervisor来获取主机资源信息）

2. 实现 instance     生命周期的管理·

3、虚拟机创建

nova-compute 创建 instance 的过程可以分为 4 步：

1. 为 instance 准备资源（根据规格flavor准备内存，cpu，硬盘等）

2. 创建 instance 的镜像文件（通过glance下载image并创建instance的镜像文件）

3. 创建 instance 的 XML 定义文件

4. 创建虚拟网络并启动虚拟机

——————————————————————————————————————————————————————————————————————————

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

这条日志我们可以得知：

1. 代码模块是 nova.virt.libvirt.config，由此可知应该是 Hypervisor Libvirt 相关的操作

2. 日志内容是生成 XML

3. 如果要跟踪源代码，可以到 /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

Openstack nova组件基本原理总结