上一节我们 shelve instance 到 Glance，本节讨论如何通过 unshelve 操作恢复该 instance。
因为 Glance 中保存了 instance 的 image，unshelve 的过程其实就是通过该 image launch 一个新的 instance，nova-scheduler 也会调度合适的计算节点来创建该 instance。
instance unshelve 后可能运行在与 shelve 之前不同的计算节点上，但 instance 的其他属性（比如 flavor，IP 等）不会改变。
下面是 Unshelve instance 的流程图
-
向 nova-api 发送请求
-
nova-api 发送消息
-
nova-scheduler 执行调度
-
nova-scheduler 发送消息
-
nova-compute 执行操作
下面我们详细讨论每一个步骤。
向 nova-api 发送请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我 Unshelve 这个 Instance”
查看日志 /opt/stack/logs/n-api.log
nova-api 发送消息
nova-api 向 Messaging（RabbitMQ）发送了一条消息：“unshelve 这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py，方法是 unshelve。
nova-scheduler 执行调度
nova-scheduler 收到消息后，会为 instance 选择合适的计算节点。 查看日志 /opt/stack/logs/n-sch.log
经过筛选，最终 devstack-controller 被选中 launch instance。
nova-scheduler 发送消息
nova-scheduler 发送消息，告诉被选中的计算节点可以 launch instance 了 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法为 select_destinations
nova-compute 执行操作
nova-compute 执行 unshelve 的过程与 launch instance 非常类似。 一样会经过如下几个步骤： 1. 为 instance 准备 CPU、内存和磁盘资源 2. 创建 instance 镜像文件 3. 创建 instance 的 XML 定义文件 4. 创建虚拟网络并启动 instance
日志记录在 /opt/stack/logs/n-cpu.log，分析留给大家练习。
以上就是 Unshelve 操作的分析，下一节我们讨论 Migrate 操作。
本文转自CloudMan6 51CTO博客，原文链接:http://blog.51cto.com/cloudman/1783688
