系统迁移

系统迁移分类:

1. 冷迁移(offline migration)
2. 热迁移(live Migration) 也叫online migration

热迁移(Live Migration)，又叫动态迁移、实时迁移

在线迁移有下面几种类型：

1. 基于共享存储的在线迁移（Live migration）: 需要实例保存在NFS共享存储中，所有的Hypervisor都可以访问共享存储，主要是实例的内存状态的迁移，速度会很快。
2. 块在线迁移（Block migration）：不要求实例存储在共享文件系统中，即无须共享存储。当各主机上vm使用的是本地存储， 而不是共享存储时， 要实现迁移， 需要实现镜像文件和内存状态同时迁移，还得迁移磁盘文件，速度会慢些。
3. 基于卷的在线迁移：实例都是基于卷的而不是临时的磁盘，无须共享存储，也支持迁移(目前仅支持基于libvirt的hypervisor)。

热迁移场景

场景 1：
物理机器硬件系统的维护，故障修复和升级(upgrade)，但运行在这台物理机器上的虚拟机不能关机，因为用户重要的服务跑在上面。

场景 2：
物理机器软件系统升级，打补丁(patch)，为了不影响上面跑的虚拟机，在升级和打补丁之前，需要把虚拟机迁移到别的物理机器上。

场景 3：
解除硬件依赖：当系统管理员需要在宿主机上升级、添加、移除某些硬件设备的时候，可以将该宿主机上运行的客户机非常安全、高效地动态迁移到其他宿主机上。在系统管理员升级硬件系统之时，使用动态迁移，可以让终端用户完全感知不到服务有任何暂停时间。

场景 3：
一个物理机器上的负载太重，需要减少一些虚拟机来释放资源。

场景 4：
实现客户机地理位置上的远程迁移：假设某公司运行某类应用服务的客户机本来仅部署在上海电信的IDC中，后来发现来自北京及其周边地区的网通用户访问量非常大，但是由于距离和网络互联带宽拥堵（如电信与网通之间的带宽）的问题，北方用户使用该服务的网络延迟较大，这时系统管理员可以将上海IDC中的部分客户机通过动态迁移部署到位于北京的网通的IDC中，从而让终端用户使用该服务的质量更高。

热迁移过程中通常会从源端发送两类模块数据到目的端，第一类数据的量很大并且虚拟机内部会不断改变这类数据，如内存，对于这类模块需要准备一个SaveVMHandlers，且在注册时会保存在SaveStateEntry的ops成员中，该结构中包含了热迁移几个阶段的回调函数，如开始时的save_setup回调、迭代过程中的save_live_iterate回调、结束过程的save_live_complete_precopy回调。第二类数据涉及的模块比较少，与QEMU本身有关，且能在热迁移的最后一个阶段迁移完成，如大量的设备状态，对于这类模块通常准备一个VMStateDescription结构并且在注册的时候会保存在SaveStateEntry的vmsd成员中，在该结构中记录了热迁移过程中需要迁移的数据以及一些回调函数。