OpenNebula 虚拟机迁移源码分析

    OpenNebula支持虚拟机的冷迁移(migrate)和热迁移（live_migrate,也可称为在线迁移），下面从代码的角度来分析下虚拟机迁移的代码执行路径。

1. OpenNebula中定义的Action的生命周期

    OpenNebula通过定义多种action来表示不同的操作，同时，OpenNebula通过一个统一的框架来处理所有的action，整个处理过程我称为action的生命周期，也可以这样理解，每个对虚拟机的操作都是由一个或多个action组成，所以，action的生命周期也可以理解为虚拟机的生命周期。

    Actions的生命周期如下图所示。

    

   对于OpenNebula的用户来说，每个对虚拟机的操作都是通过RPC请求发起的(rpc的原理和机制不熟悉的同学，可以参见前面的文章《opennebula源码分析 -- XML-RPC 原理分析 》），RPC server(OpenNebula节点)接收到RPC请求后，会进行如下的处理和操作：

    （1）将RPC请求转化为DM（DispatchManager）类的action， DM类负责ation的派发工作

    （2）DM类将action又转化为LCM（LifeCycleManager）类的action，LCM类负责虚拟机的生命状态的设置，如用户看到的Pending，Prolog，Boot，Running，Failed等状态

    （3）LCM类将action又转化为VMM类的（VirtualMachineManager）action，VMM类负责虚拟机相关的实际操作，如创建，删除等，这里的实际操作指的是通过virsh命令执行的操作

    （4）VMM类将通过ssh，登录到物理机上执行virsh命令，来完成action代表的用户的请求

    以Migrate为例，看一下在整个migrate action的生命周期中，虚拟机的状态的变化。

           RUNNING  -->  SAVE_MIGRATE --> PENDING --> PROLOG --> BOOT --> RUNNING

    首先，只有处于RUNNING状态的虚拟机才能进行迁移操作；其次，迁移之前首先要SAVE当前的虚拟机；再次，将SAVE好的虚拟机拷贝到要迁移到的主机；最后，就是一个虚拟机部署操作的生命周期了！

2. Migrate action相关的代码执行流程

3. libvirt层的迁移命令

(1)冷迁移：

    virsh  migrate vm0 qemu+ssh://192.168.35..16/system

将名称为vm0的虚拟机通过ssh协议迁移到主机192.168.35.17上

(2)在线迁移：

    virsh  migrate --live vm0 qemu+ssh://192.168.35.16/system

这里都采用了ssh来进行数据传输，其实还可以利用tcp，如：

    virsh  migrate vm0 qemu+tcp://192.168.35..16/system