基于KVM的 虚拟机在线迁移方案在UCloud平台的实践（V1.0）.docx

基于KVM的虚拟机在线迁移技术在UCloud平台的实践 虚拟机在线迁移技术出现的背景 服务器虚拟化一经出现就被视为IT界的game-changing技术，其带来的好处和变革对传统IDC影响巨大。其主要的好处或者目标，例如故障隔离、节能环保、提高资源利用率、故障快速恢复等等，都和虚拟化技术本质属性直接相关。虚拟化的本质是将服务器上的硬件资源经过虚拟化技术变成一个可以拆分的资源，拆分后的资源也就是一个个虚拟主机，都拥有完整的原有硬件可提供的服务能力。 虚拟化要真正达到上面所述的好处或者目标，除了其技术本身提供的能力外，还有赖于云服务商本身的运营能力及技术改造。例如提高资源利用率，这个目标的社会价值巨大，因为这个意味着可以减少资源的浪费或者同等的资源可以提供更大的服务能力，但这个会给云服务商带来两个挑战，一是如何将一台虚拟机分配到一台空闲的物理服务器上以提高物理服务器的资源利用率，二是在提高物理服务器资源利用率的同时如何避免对该物理服务器上的虚拟机的影响，也就是著名的Nosiy Neighbors Problem。 两个挑战分别对应资源的静态分配和动态调度。第一个挑战，是数学上的装箱问题，在物理机集群规模大小不一样情况下，求最优解的方式和成本不一样，这里不打算展开说。对于第二挑战，需要多种手段配合使用，例如将物理机的存储，内存作为一个个分布式的服务提供出去，减少对单机容量的依赖，UCloud有对应的产品可供使用，例如UDisk对应存储，UMem对应内存。另外虚拟化技术底层也提供了一个杀手级的方案，那就虚拟机的在线迁移方案。 虚拟机在线迁移技术的原理 所谓在线迁移，也就是可以在不停机的情况，将虚拟机从一台物理机迁移到另外一台物理机，迁移过程不影响虚拟机的正常运行，也就不会影响用户跑在虚拟机上的业务。 在线迁移是如何做到在几乎不停机的情况将一台虚拟机完整的迁移到另外一个物理服务上的呢，这个估计是很多人都感兴趣的问题。要解答这个问题，首先要搞清楚一台虚拟机的完整迁移涉及到哪些数据需要迁移。虚拟机的数据分为三类， 磁盘，内存，设备状态（例如虚拟CPU寄存器）。清楚这个问题之后，在线迁移剩下的就是如何把这三类数据在保证一致的情况下迁移到另外一台宿主机。 下文拿基于KVM虚拟化方案（底层为kvm，模拟器为qemu, 管理器为libvirt）的在线迁移为例，说明在线迁移这个目标是如何达成的，KVM的在线迁移分为两类，一类是带共享存储的迁移，这一类只需迁移内存+设备状态即可，另外一类是带块设备的迁移，也就是需要迁移磁盘、内存和设备状态。这里重点说下第二类，因为第一类是第二类的一个特例。第二类也有若干种细分，这里只讨论带块设备的完整迁移的方案。数据的迁移基于tcp协议通过网络来传输完成的，因此迁移之前必须保证两台物理机在网络上是必须通的。假设将从将源物理机SourceHost的一个虚拟机VM-A 迁移到目标物理机DestHost，带块设备的在线迁移过程如下： Step.1 在DestHost上创建VM-A的对应的系统盘和数据盘,两个磁盘在DestHost上的路径和SourceHost上的路径必须完全一致，不同的是，创建的是空盘，上面没有数据。 图1 Step.2 通过虚拟化管理软件Libvirt在DestHost上创建一个和VM-A同样配置的虚拟机VM-A’，系统盘和数据盘使用Step.1中创建的系统盘和数据盘。VM-A’当前状态是paused状态，虚拟cpu是暂停状态，用户态的模拟器qemu进程会监听一个内网的tcp端口，用于接收迁移的数据。 图2 Step.3 虚拟化的管理层Libvirt给VM-A对应的qemu进程发出一个迁移指令，并指定参数，例如指定DestHost为目标、指定需要迁移块设备、最大的停机时间、迁移的带宽限制等等。注意，迁移数据的网络包不是经过 vswitch, 而是直接走SourceHost ethx网卡出，进到DestHost的ethx，因为VM-A’对应的qemu进程是作为DestHost一个用户态进程监听在ethx对应的内网ip. 我们将Step2的图转换成qemu进程可以看得清晰一点. 图3 Step.4 经过前面三步，虚拟机的数据就开始迁移了，剩下的挑战是怎么保证数据的迁移是一致的，因为这个时候VM-A是运行状态，里面时刻发生内存更新、磁盘io操作和设备状态变更，而VM-A’是paused是状态，只是通过一个线程来接收VM-A进程发过来的数据，这个迁移过程结束依据是什么呢？数据一致性和什么时候结束迁移，这两个问题其实是一个问题，那就是虚拟机迁移完成的标准是什么？qemu里面是这样解决的，每个虚拟机在创建的时候，都会注册块设备的在线迁移函数、内存的迁移函数（对于设备状态而言，没有对应的在线迁移函数，因为设备状