静态迁移
静态迁移，即离线迁移（ ），是在虚拟机关闭（ ）或暂停（暂停）时从一台物理机迁移到另一台物理机。 由于虚拟机内部的文件系统是建立在虚拟机的虚拟磁盘文件之上的，所以当虚拟机关闭时，只需要简单地将虚拟机的虚拟磁盘文件和相应的配置文件迁移到另一个虚拟机上即可。物理主机。 当虚拟机挂起时，虚拟机当前的运行上下文（CPU和内存）仍然在源主机的内存中，因此除了迁移虚拟磁盘文件和配置文件外，还需要复制将虚拟机的运行上下文发送到目标主机，最后在目标主机上加载虚拟机运行上下文，然后虚拟机()运行。 在这种情况下，迁移过程需要显式停止虚拟机的运行。 从用户的角度来看，虚拟机上运行的服务将在一段时间内不可用。 这种迁移方法非常简单，适用于对服务可用性（）要求不严格的场合。
实时迁移
实时迁移（Live ），又称为在线迁移（ ），这种迁移方式将虚拟机从源主机移动到目标主机，同时需要保证虚拟机上的服务在迁移过程中正常运行。迁移过程。 此过程不会对最终用户产生重大影响，以便管理员可以对物理服务器进行离线维护或升级，而不会影响用户的正常使用。 与静态迁移不同的是，为了保证迁移过程中虚拟机服务的可用性，迁移过程中只有很短的停机时间。 在迁移准备阶段，服务运行在源主机的虚拟机上。 当迁移到达某个阶段时，目标主机已经拥有运行虚拟机所需的资源。 经过很短的切换后，源主机将控制权转移到目标主机，然后虚拟机继续在目标主机上运行。 对于虚拟机服务本身来说，由于切换时间很短，用户感觉不到服务中断，因此迁移过程对用户来说是透明的。 热迁移适用于对虚拟机服务高可用性要求的场合。
虚拟机在不同平台之间动态迁移
该方法在不同主机之间迁移虚拟机（例如，在KVM与KVM之间迁移虚拟机）。 虽然现实中还没有看到如此大规模的应用，但技术难度并不大。 原则上我们需要不同平台提供相互兼容的接口来处理以下资源的转换，
虚拟机配置文件
它不是简单的配置文件格式转换。 例如，向VM提供不同的时钟。 想象一下，VM拥有的所有资源都迁移到目标主机，然后VM被删除。 VM内部，时钟和其他设备是依次排列的。 但是，提供的虚拟时钟不同，VM还能有正常的时钟吗？ 如果不行的话还能正常工作并继续工作吗？ ）
虚拟机内存转储
我们还期望不同转储的VM内存是统一的格式（例如ELF），但现实通常并不那么美好
虚拟机磁盘镜像文件
实现转换比较容易，各种虚拟磁盘格式都可以找到对应的开源实现
不考虑 PCI-/vGPU/TPM 等特殊应用
可能有一些组织或个人会声称他们已经实现了不同虚拟机之间的虚拟机迁移。 笔者也遇到过这种情况。 然而这个组织的实现方法却非常简单粗暴。 读者应该或多或少听说过，执行虚拟机迁移的程序最初会将虚拟机当前的所有内存转储从源主机传输到目标主机。 在此期间，VM内部程序仍然处于活动状态，这会导致VM内存发生变化。 ，那么执行VM迁移的程序需要再次去将这段时间更新的内存（以下简称diff）从源主机同步到目标主机，执行VM迁移的程序会轮询，直到进程收敛。 在少数不收敛的情况下，VM迁移程序执行8到15个周期，然后对VM执行暂停操作，然后执行最后一次VM内存同步。 这个过程与文件同步工具rsync的工作流程非常相似。 那么这种简单粗暴的方法是如何实现的呢？ 执行VM迁移的程序不会计算差异。 每次源主机和目标主机之间同步VM内存时，都是VM内存的完整副本。 这种情况下，源主机端的发送程序就非常简单了。 执行dump操作（提供该接口）获取VM内存，然后发送出去。 目标主机端的接收程序收到新的VM内存后，直接覆盖之前的内存，然后进行转换。 格式化，然后执行load操作（提供此接口）重置VM内存。 可以看到这种方法工作量比较少，只需要在接收程序中实现格式转换函数即可。 当然，这也是一种方法，但是效率太低了。 一般情况下，有多少人愿意花钱购买这样的软件产品呢？
从时间顺序来看，虚拟机热迁移技术经历了以下几种形式：
1、基于共享存储的虚拟机热迁移，以下简称VM live。 这种动态迁移的方式要求源主机和目标主机必须采用SAN（区域）或NAS（NAS）等集中式存储技术，共享相同的存储资源（见图1）。 迁移虚拟机配置和虚拟机内存执行状态，因此具有更好的迁移性能。
图1. 基于共享存储的虚拟机动态迁移
2、非共享存储的虚拟机实时迁移，下面我们用VM来描述。 基于共享存储的热迁移技术限制了虚拟机的迁移范围。 非共享存储热迁移技术的出现解决了虚拟机远程迁移的实际问题。 请参阅图 2 了解部署示例。
图 2. 具有非共享存储的虚拟机的实时迁移
3、前两种方式的热迁移有限制。 虚拟机迁移的源主机和目标主机的CPU型号必须相同（此问题将在后续章节中进行说明）。 这给实际生产带来了另一个问题。 在数据中心中，随着时间的推移，主机的CPU会逐渐更新。 如何将旧CPU主机上运行的虚拟机动态迁移到新主机上？ ？ 直观上来说，如果新CPU能够降级到与旧CPU相同的配置，那么理论上就可以在不同CPU的主机上实现虚拟机的动态迁移。
商业软件在执行直播之前会执行一系列操作，以验证用户提交的直播应用是否满足条件。 作为一个商业产品，这些繁琐的工作是必须要做的，但这不是直播技术的核心，我们这里不讨论这些。 关于VM live的详细流程，我们参考Xen的实现，如图：
迁移过程
结合图3，虚拟机动态迁移分为以下步骤，
1.. 前面说了，这个阶段的工作并不是live的核心，所以这里就不讨论了。
2.预处理。 源主机上运行的发送程序将VM的配置信息发送给目标主机上运行的接收程序，然后接收程序根据配置信息在目标主机上创建一个新的VM（此时VM具有运行所需的资源，但图像尚未加载，因此还无法运行）。
3. 迭代。 源主机上负责迁移的程序通知VM开关打开，然后将VM内存页对应的PTE（条目）的读/写属性位设置为只读。 如果在迁移过程中VM的某些内存页被更新，则在故障处理时会记录这些更新的内存页，以便负责迁移的程序在下一次迭代时可以获知哪些内存页被更新了。 问题：EPT（表）PTE中的/dirty位可以用来实现同样的功能吗？
源主机侧的迁移程序在第一次迭代时将VM拥有的所有内存页发送到目标主机，目标主机侧的接收程序负责将接收到的内存页加载到VM的空间中。 在后续迭代中，源主机仅复制先前传输中修改的页面，直到进程收敛。 在实际生产环境中，会存在不收敛的情况。 根据经验规则，通常执行8到15次迭代。
4. 停止并复制。 源主机上负责迁移的程序冻结VM的运行，然后将vCPU上下文、剩余的不一致内存页面和Qemu发送到目标主机。 此阶段，源主机和目标主机均具有VM实例（均处于冻结状态）。 如果中间出现错误，整个过程失败，则源主机端恢复VM，并告知目标主机端销毁新创建的VM。
5、源主机销毁VM，并通知目标主机，目标主机执行VM，然后回复源主机确认。
潜在问题
1.上面提到了迁移主要分为几个步骤，其中有可能，
1.1.
1.2. 虚拟机
1.3. Qemu 保存状态
在Xen的实现中，上述三个操作都是异步的，负责VM迁移的程序需要通过监控知道这些异步操作是否已经成功完成。 监控可能会发生，特别是在重负载的情况下。 另外，已经证明，的实现存在性能和可扩展性问题。
2、相位通讯故障
如上所述，源主机和目标主机需要通过两阶段握手来确认对方的状态。 如果握手过程中通信失败，虚拟机可能同时在源主机和目标主机上运行。
性能改进
1. 硬件提供的选择
PML（页面），其功能与上面提到的相同。 不同的是，内存分页是通过软件实现的（中间必须报警缺页错误），不可避免地会带来； PML自动记录脏GPA（guest，虚拟机内核看到的物理内存地址）。 每当EPT PTE（上面提到的）的脏位从0变为1时，PML就会将脏GPA写入4K内存区域。 为了支持PML，需要在VMCS（虚拟机控制块，VT-x技术主要是通过操作VMCS结构来实现）中添加4K内存块地址，同时VMCS还需要添加一个PML索引，初始值该索引的值为512（GPA长度为8字节，4K/8Byte=512），每当记录脏GPA时，索引值减1，当索引值为0时（即4K内存已满） ），该事件会被触发，VM会被剥夺CPU使用权，VM内核会陷入其中，然后更新内部脏，等待程序迁移VM进行查询。 可以看出，与软件实现相比，PML并没有引入更具争议性的页面错误，但仅在记录512条记录时发生一次，理论上减少了VM处于模式时的开销。 总的来说，PML给虚拟机迁移带来的好处是普遍的。
2、软件性能提升
我们讨论了加速虚拟机迁移的硬件辅助技术。 让我们看看在软件层面是否有机会提高虚拟机迁移性能。
2.1. 零页
什么是零页？ 为避免歧义，可能有不同的解释，即4K缓存内容全部为0内存页（不考虑）。 人们很容易认为VM进程期间的传输是没有意义的，因为VM运行时零页不包含数据/指令。 理论上，为了处理零页，迁移后的VM的发送程序只需要向接收程序发送一个数组，每个数组元素的值对应零页的gpfn（guest ）。 将得到的gpfn数组零页（如果不考虑潜在的信息泄漏，可以只分页而不将页内容清为0）填充VM内存映像，然后执行load操作重置VM内存。 对于具有大量零页的虚拟机来说，这种迁移过程节省了大量的网络传输开销。
要实现这种方法，首先要扫描整个VM内存地址空间来查找全部（如何快速高效地判断某个内存页的内容是否全为0？考虑对齐）。 如果最后检测到的零页很少或没有，显然，这反过来又增加了虚拟机迁移的开销。 幸运的是，搜索零页的时间复杂度是O(size)，是一个线性过程。
2.2. 页
与之前的方法类似，内存页压缩的原理是尽量减少VM迁移过程中网络传输的开销。 同样，内存页压缩也会引入额外的开销（无论压缩过程是基于编码还是基于内容匹配），而且压缩算法的复杂度显然比零页搜索要高得多。 因此，也引入了一个需要权衡的问题。 节省的网络传输开销能否弥补压缩算法带来的开销？ 对于这样的问题很难下结论，只能具体情况具体分析。
2.3.
如果一个线程不行，很自然就会想到使用多线程进行传输。 甚至，将上述两种方式结合起来，由一个独立线程负责压缩，另一个独立线程进行传输。
看来这个方法也是通用的。 但是，不要忘记，当迁移VM的程序从单线程变为多线程时，主机的压力也会增加，这可能会导致主机上运行的出现故障。 响应延迟。
一般来说，软件层面的性能提升方法都有一些适用的前提，不能像硬件提供的选项那样普遍适用； 当然，使用硬件提供的方法通常意味着要花更多的钱购买更先进的设备。
