Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack（40）

Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack（40）

Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上。

Migrate 不要求源和目标节点必须共享存储，当然共享存储也是可以的。 Migrate 前必须满足一个条件：计算节点间需要配置 nova 用户无密码访问。

下面是 Migrate instance 的流程图

下面我们详细讨论每一个步骤。

向 nova-api 发送请求

客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我迁移这个 Instance” Migrate 操作是特权操作，只能在 Admin 的 instance 菜单中执行

查看日志 /opt/stack/logs/n-api.log

nova-api 发送消息

nova-scheduler 执行调度

nova-scheduler 收到消息后，会为 instance 选择合适的目标计算节点。 查看日志 /opt/stack/logs/n-sch.log

看到上面的日志，大家发现什么问题没有？

在分析这段日志的时候，我发现 scheduler 选出来的计算节点有可能是当前节点源节点！ 因为 scheduler 并没在初始的时候将源节点剔除掉，而是与其他节点放在一起做 filter，按照这个逻辑，只要源节点的权值足够大，是有可能成为目标节点的。

那紧接着的问题是：如果源节点和目标节点是同一个，migrate 操作会怎样进行呢？

nova-scheduler 发送消息

nova-scheduler 发送消息，通知计算节点可以迁移 instance 了。 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法为 select_destinations

源计算节点 devstack-controller

迁移操作在源节点上首先会关闭 instance，然后将 instance 的镜像文件传到目标节点上。 日志在 /opt/stack/logs/n-cpu.log，具体步骤如下：

开始 migrate

在目标节点上创建 instance 的目录

如果 touch 失败，说明目标节点上还没有该 instance 的目录，也就是说，源节点和目标节点没有共享存储。那么接下来就要在目标节点上创建 instance 的目录，日志如下

关闭 instance

将 instance 的镜像文件通过 scp 传到目标节点上

在目标节点上启动 instance，过程与 launch instance 非常类似。 会经过如下几个步骤： 1. 为 instance 准备 CPU、内存和磁盘资源 2. 创建 instance 镜像文件 3. 创建 instance 的 XML 定义文件 4. 创建虚拟网络并启动 instance

日志记录在 /opt/stack/logs/n-cpu.log，分析留给大家练习。

Confirm

这时，instance 会处于 “Confirm or Revert Resize/Migrate”状态，需要用户确认或者回退当前的迁移操作，实际上给了用户一个反悔的机会。

当我们按下 Confirm 按钮后，会发生如下事情：

Revert

如果执行的是 Revert 操作会发生什么事情呢？

以上是 Migrate 操作的详细分析，下一节我们讨论 Resize。