虚拟机是公共云服务提供商的核心产品形态，故 虚拟化技术 也是弹性计算技术中的核心技术之一。虚拟化技术涉及 计算虚拟化、存储虚拟化、网络虚拟化、管控调度 等方面，本文主要介绍其中的计算虚拟化技术，以阿里云的虚拟化技术发展历程作为开篇概述，再介绍业界流行的 KVM 虚拟化技术，最后概括介绍云计算中虚拟化的 热迁移 和 热升级 这两大关键技术。

1.虚拟化技术的发展历程

虚拟化技术是云计算的重要技术之一，在被云计算采用之后就不断演进发展。虚拟化技术在阿里云的历史正好是这个演进发展过程的一个缩影，所以下面就以阿里云为例先来讲述一下阿里云虚拟化技术发展历程，如下图所示，然后重点介绍后期的 KVM 和软硬一体的虚拟化技术。

1.1 Xen 虚拟化架构（2009 ~ 2015 年）

2009 年，在阿里云刚成立之时，在开源虚拟化技术领域中，Xen 已经是比较成熟的虚拟机监控器项目，所以阿里云采用开源的 Xen 作为第一个虚拟化底层架构。当时，阿里云将 Xen 开源项目应用在公共云上，做了一些修改，解决了 Xen 在公共云应用中的大规模工程化方面的各种细节问题。在这个时期，亚马逊 AWS 的虚拟化架构使用的也是 Xen，这种选择也是当时业界的共识。

🚀 XEN 最初是剑桥大学 Xensource 的一个开源研究项目，2003 年 9 月发布了首个版本 Xen 1.0，2007 年 Xensource 被 Citrix 公司收购，开源 Xen 转由 xen.org 继续推进，该组织成员包括个人和公司（如 Citrix、Oracle 等）。2014 年 3 月 11 日，Xen 发布 4.4 版本，更好地支持 ARM 架构。

🚀 Xen 是运行在裸机上的 虚拟化管理程序（HyperVisor），是 半虚拟化（Para-Virtualization）技术的典型代表。英文前缀 Para 直译为 “侧”、“旁”、“近旁” 的意思，Para-Virtualization 可以理解为 “在 Guest VM 旁边运行着的管理 VM”，Xen 称这个特别的 VM 为 Dom0，虚拟机操作系统被称做 DomU。管理 VM 负责管理整个硬件平台上的所有输入输出设备驱动，半虚拟化中的 Hypervisor 不对 I/O 设备作模拟，而仅仅对 CPU 和内存做模拟，这就是 Para-Virtualization 被翻译成 “半虚拟化” 的原因。半虚拟化还有一个叫法：操作系统辅助虚拟化（OS Assisted Virtualization），这是因为 Guest VM 自身不带设备驱动，需要向 “管理 VM” 寻求帮助。这种虚拟化技术允许虚拟化操作系统感知到自己运行在 XEN HyperVisor 上而不是直接运行在硬件上，同时也可以识别出其他运行在相同环境中的虚拟机。

KVM_2015__2018__14">1.2 KVM 虚拟化架构（2015 ~ 2018 年）

2005 年、2006 年，Intel 和 AMD 的 x86 CPU 硬件分别开始支持 硬件虚拟化（VT）技术，并在 2006 年诞生了 KVM（Kernel-based Virtual Machine）这个基于硬件虚拟化的开源虚拟化项目。红帽（RedHat）公司在 2008 年收购了开发 KVM 的以色列公司 Qumranet 后，KVM 更是得到了大力的发展。2014 年左右，KVM 在功能完备性、稳定性、社区支持等各个方面都超过了 Xen，这时阿里云也开始研发基于 KVM 的云服务器，最终在 2015 年将虚拟化架构迁移到了 KVM 上。在 2015 ~ 2018 年，阿里云不仅使用 KVM 解决了工程化的问题，也做了 QEMU/KVM 的热升级等原创工作，自研了 vCPU 的调度器，支持性能突发型实例规格（T5）的产品，同时对热迁移等重要功能做了比较好的优化。

🚀 QEMU 是一个快捷的跨平台开源计算机模拟器，可以模拟许多硬件体系结构。QEMU 可让您在现有系统（VM 主机服务器）之上运行未经修改的完整操作系统 (VM Guest)。您还可以使用 QEMU 进行调试 — 可以轻松停止正在运行的虚拟机、检查其状态、保存并在以后恢复其状态。

🚀 QEMU 是纯软件实现的虚拟化模拟器，几乎可以模拟任何硬件设备，我们最熟悉的就是能够模拟一台能够独立运行操作系统的虚拟机，虚拟机认为自己和硬件打交道，但其实是和 QEMU 模拟出来的硬件打交道，QEMU 将这些指令转译给真正的硬件。

🚀 正因为 QEMU 是纯软件实现的，所有的指令都要经 QEMU 过一手，性能非常低，所以，在生产环境中，大多数的做法都是配合 KVM 来完成虚拟化工作，因为 KVM 是硬件辅助的虚拟化技术，主要负责比较繁琐的 CPU 和内存虚拟化，而 QEMU 则负责 I/O 虚拟化，两者合作各自发挥自身的优势，相得益彰。

1.3 软硬件结合的虚拟化架构（2018 年至今）

在 KVM 虚拟化技术比较成熟的情况下，在下一代的虚拟化架构演进方向上，包括亚马逊 AWS、阿里云等云服务提供商仿佛达成默契，都在 软硬件结合 的方向上投入研发。AWS 在 2017 年年底对外发布了基于 Nitro 架构的 C5 实例规格，阿里云在 2017 年也发布了基于神龙架构的弹性裸金属服务器，并在 2018 年上线了基于神龙架构的虚拟机云服务器。神龙架构是阿里云自研的软硬件结合的虚拟化平台，其中的 MOC 卡 是神龙架构中的核心硬件，将存储、网络、管控的链路全部转移到 MOC 上，同时对 KVM 虚拟化技术做进一步优化，以提升计算性能。

近些年，随着云计算规模体量的增大、研发人力物力的大量投入，虚拟化架构的演进速度进一步加快。另外，软硬件结合的神龙架构也在持续迭代，神龙 1.0、2.0、3.0 等架构的升级一直都在持续进行中。

KVM__27">2.KVM 虚拟化技术

KVM 是基于 CPU 硬件虚拟化技术（如 Intel 的 VT-x、AMD 的 AMD-V 等）的全虚拟化技术，是业界多数公共云和专有云服务提供商使用最多的虚拟化技术之一。KVM 虚拟化技术的核心主要由两个模块组成。

• KVM 内核模块。它属于标准 Linux 内核的一部分，是一个专门提供虚拟化功能的模块，主要负责 CPU 和内存的虚拟化，包括客户机的创建、虚拟内存的分配、 CPU 执行模式的切换、vCPU 寄存器的访问和 vCPU 的执行。
• QEMU 用户态工具。它是一个普通的 Linux 进程，为客户机提供设备模拟的功能，包括模拟 BIOS、PCI/PCIe 总线、磁盘、网卡、显卡、声卡、键盘和鼠标等，同时它通过 ioctl 系统调用与内核态的 KVM 模块进行交互。

KVM 是在硬件虚拟化支持下的完全虚拟化技术，因此它可以支持在相应硬件上能够运行的几乎所有的操作系统，如 Linux、Windows、FreeBSD、macOS 等。QEMU/KVM 虚拟化基础架构如下图所示。在 KVM 虚拟化架构下，每个虚拟机就是一个 QEMU 进程，即在一个宿主机上有几个虚拟机就会有几个 QEMU 进程；客户机中的每一个虚拟 CPU 对应 QEMU 进程中的一个执行线程；一个宿主机中只有一个 KVM 内核模块（当然也可以使用多个 KVM 模块以提高可用性），所有客户机都与这个内核模块进行交互。

3.热迁移技术

在虚拟化环境中的虚拟机迁移分为 冷迁移 和 热迁移，也称为 离线迁移 和 在线迁移。冷迁移和热迁移最大的区别就是，在冷迁移中明显有一段时间（可能是几秒钟或者几分钟），虚拟机中的服务不可用，而热迁移则没有明显的服务暂停时间。虚拟化环境中的冷迁移也可以分为两种。

• 关闭虚拟机后，将其硬盘镜像复制到另一台宿主机上，然后启动，这种迁移不能保留虚拟机中工作负载的运行时状态。
• 两台宿主机共享存储系统，只需要在暂停（而不是完全关闭）虚拟机后，复制其内存镜像到另一台宿主机中后启动，这种迁移可以保持虚拟机迁移前的内存状态和系统运行的工作负载。

热迁移（Live Migration）指 在保证虚拟机上的应用服务正常运行的同时，让虚拟机在不同的宿主机之间迁移。其逻辑步骤与前面的冷迁移几乎一致，有磁盘和内存都复制的热迁移，也有仅复制内存镜像的热迁移；不同于冷迁移的是，为了保证迁移过程中虚拟机服务的可用性，热迁移过程仅有非常短暂的停机时间，以至于虚拟机中的应用程序几乎没有任何感知。 KVM 下的热迁移如下图所示。

虚拟机热迁移增强的是系统的可维护性，其主要目标是在用户没有感知的情况下，将虚拟机迁移到另一台物理机上，并保证其各个服务都能正常使用。主要从以下两个方面来衡量虚拟机迁移的效率。

• 整体迁移时间。整体迁移时间指从源主机（Source Host）迁移操作开始，到虚拟机被迁移到目的主机（Destination Host），并恢复其服务所花费的时间。
• 服务暂停时间（Service Down-Time）。服务暂停时间指在迁移过程中，源主机和目的主机上虚拟机的服务都处于不可用状态的时间。此时，源主机上的虚拟机已暂停服务，目的主机上的虚拟机还未恢复服务。

由于服务暂停时间是用户可以真切感受得到的，所以它也更为重要。热迁移的服务暂停时间，受虚拟机的工作负载（如 CPU、内存、网络、磁盘等压力）、宿主机计算性能和网络带宽等因素的影响，一般在几毫秒到几秒不等。

在阿里云这样的大型公共云上，热迁移具有广泛的用途，比如硬件升级与维护、宿主机内核升级、动态调度资源等。目前热迁移也是阿里云 ECS 的核心竞争力之一。在阿里云真实场景下热迁移的链路是比较长的，需要管控系统、虚拟化、存储、网络的各个组件相互配合才能实现，公共云上的热迁移过程如下图所示。

KVM 热迁移的关键步骤如下图所示。

为了进一步缩短服务停机时间，提升热迁移的用户体验，阿里云 ECS 进行了如下 3 个方面的热迁移优化，如下图所示。

• 1️⃣ 对关键步骤进行最大限度的并行。
• 2️⃣ 将非关键的操作预处理或延后处理，使其不阻碍热迁移的关键步骤。
• 3️⃣ 将核心控制权下移到虚拟化层处理。

由于热迁移中的 服务停机时间 与 虚拟机的负载 相关度很高，为了进一步优化阿里云 ECS 的热迁移体验，将人工智能技术引入热迁移流程中，用于 预测虚拟机的负载趋势和最佳迁移时间点，尽可能地让热迁移发生在虚拟机负载较低的时刻，这样对用户的业务影响最小。

这些优化的最终落地，使得阿里云 ECS 热迁移的用户体验大幅提升，目前多数小规格虚拟机的服务停机时间在 100 毫秒以内，而稍大规格虚拟机的热迁移服务停机时间一般都能控制在几百毫秒内。

4.热升级技术

云计算中的 热升级技术 指 在客户业务基本无感知的情况下，对云计算基础设施的组件进行升级操作。在阿里云弹性计算服务的技术框架中，我们设计了一套针对 QEMU/KVM 等核心虚拟化组件的热升级系统，并在生产环境的成千上万的虚拟机上进行了广泛应用。

在弹性计算服务中，我们持续为客户增加新的功能，经常要修改 QEMU/KVM 等虚拟化监控器软件。由于虚拟机软件都会有一些缺陷，而且部分缺陷还会导致安全方面的风险，所以需要对运行中的虚拟机及虚拟化软件进行升级。因为对这些升级的请求比较频繁，而且针对的是云上数以百万计的虚拟机，所以必须尽可能地缩短客户虚拟机的服务中断时间。在已经存在的传统技术中，内核热补丁技术 和上一节介绍的 虚拟机热迁移技术 能满足这样的需求。不过，在实际的大规模应用中，它们都有一些弊端，因此我们针对这样的升级需求开发了阿里云独特的 虚拟化热升级技术。下表对这三种热升级技术进行了比较。

4.1 内核热补丁

内核热补丁技术 能够在不重启系统的情况下对内核打补丁，修复问题。它让运行中的系统基本感受不到服务中断。但是它不能修复较为复杂的问题，比如对持久性数据结构的改动或者添加新功能；同时它只能针对内核模块进行升级。这种技术主要适用于修复较为简单的 Linux 内核（包括 KVM 模块）的安全问题。

4.2 虚拟机热迁移

热迁移技术 是云服务提供商中经常用于软件升级的技术，阿里云也将热迁移技术大量用于物理硬件维修、虚拟机库存动态调度等场景。热迁移需要复制源主机上虚拟机的状态（如内存）到另外一个空闲备用的目的主机上，在最后一轮状态传输时，停止正在运行的虚拟机，复制最后一次改变的状态，最后在目的宿主机上启动虚拟机，恢复运行状态。

通过热迁移技术，云服务提供商可以升级服务器上所有软件，如宿主机内核、虚拟化软件、损坏的硬件设备等。不过，在大规模的云计算数据中心中，热迁移也受到一些限制，比如它需要额外的空闲服务器才能迁移；在迁移过程中需要较大的网络带宽，如果大量虚拟机同时做热迁移可能造成一些网络拥塞；热迁移的内存迭代拷贝需要消耗一些 CPU 计算资源，并且最后会停止虚拟机，这个过程对虚拟机运行的性能有损坏并会产生一小段的服务中断时间；云上有不少 GPU/FPGA 等设备直通的虚拟机，目前还不能支持带直通设备的热迁移。

4.3 阿里云的虚拟化热升级

阿里云的 虚拟化热升级技术 尽可能吸取上述两种方法的优点，改进它们的不足。阿里云的虚拟化热升级技术支持整个虚拟化软件栈（主要是用户态的 QEMU 和内核态的 KVM 模块）的热升级，能实现云计算环境下较为复杂的新功能的热升级，比如热升级支持一种新的分布式存储系统。它避免了热迁移的劣势，不需要额外的服务器和网络带宽，同时虚拟机上感知到的服务中断时间比热迁移短得多。尽管它没有像热迁移那样实现全新的主机切换，但是在云环境下一般来说也是够用的。以 KVM 虚拟化为例，主机的内核是相对独立的，用户虚拟机的新功能开发一般只要改动 QEMU/KVM 即可实现（对 KVM 在 2018 年公布的 90 多个缺陷进行统计，其中 98% 的缺陷发生在 QEMU/KVM 上，通过热升级都可以解决）。

阿里云虚拟化热升级技术里面有三个关键的技术点 ：双 KVM 内核模块、虚拟机嫁接、直通设备移交。下面分别对其做简单的介绍。

KVM__80">4.3.1 双 KVM 内核模块

以 Intel 硬件平台下的 KVM 为例，普通的 KVM 架构有一个与架构无关的 kvm.ko 模块，还有一个管理 Intel 硬件虚拟化的 kvm-intel.ko 模块。在热升级框架下，我们做了 kvm-intel-0.ko 和 kvm-Intel-1.ko 两个模块，以便实现 KVM 模块的热升级，如下图所示。我们尽可能地将 kvm.ko 模块中多数的功能都移到 kvm-intel-0.ko 模块中，让 kvm.ko 模块尽可能 “薄”。在一般情况下，它不需要热升级，只需要升级架构相关的 kvm-intel.ko 模块即可。当我们加载 kvm-intel-0.ko、kvm-intel-1.ko 模块时，会创建相应的 /dev/kvm0、/dev/kvm1 等设备节点文件，用于 QEMU 与 KVM 内核模块的交互。

4.3.2 虚拟机嫁接

在 KVM 上，一个 QEMU 进程代表一个虚拟机。虚拟机包括内存、虚拟 CPU、存储、网卡等，都是由 QEMU 进程来分配和管理的。将一个虚拟机从前面提到的 kvm0 迁移到 kvm1 上，本来可以使用本地热迁移技术，不过这样就需要两份相同大小的虚拟机内存，对于内存数量很大的虚拟机而言，会浪费不少内存资源。在阿里云虚拟化热升级技术中，通过 “虚拟机嫁接” 将虚拟机的内存和内部状态从一个 KVM 实例嫁接到另一个 KVM 实例之上，如下图所示。

我们先将虚拟机的内存标为 reserved 状态，然后派生一个新的 QEMU 子进程，调用 QEMU 中的 savevm_state 函数保存原来虚拟机的内部状态并暂停虚拟机运行，之后在新的 QEMU 子进程中调用 execve() 函数加载升级后的 QEMU 程序文件，并通过 loadvm_state 函数恢复虚拟机的状态。

在这个过程中，但凡有任何的失败，系统都会让最初暂停的 QEMU 进程重新恢复原来的状态。

在具体实现中，需要让新的 QEMU 进程在 execve() 函数执行后，能够保留原虚拟机的内存。由于在默认情况下 execve() 函数并不支持内存的保留，所以我们在宿主机的 Linux 内核中对 mmap 函数进行了简单的改造，添加了 MAP_KVM_RESERVED 这样一个专用于 QEMU/KVM 热升级的标志。

4.3.3 直通设备移交

大型的云服务提供商有不少的计算服务通过将 GPU 或 FPGA 设备直通给虚拟机，来加速用户的诸如深度学习、人工智能相关的应用程序。使用 Intel VT-d 技术实现设备直通，可让虚拟机直接访问硬件设备。现代设备的访问都是由 DMA（直接内存访问）来完成的，在虚拟化直通设备的情况下，DMA 访问所需的从 GPA（虚拟机物理地址）到 HPA（物理机物理地址）的转化，是由 IOMMU 来实现的。如果实现带有直通设备的虚拟机的热升级，那么需要迁移设备的内部状态，重建 IOMMU 重映射表，保存和恢复正在进行的 DMA 操作以免造成数据丢失。这是比较复杂的情况，而且没有现成框架可以使用。

在阿里云虚拟化热升级技术中，我们使用了 “直通设备移交” 的方式来实现直通设备的热升级。由于我们都是使用 VFIO 这个框架来实现设备直通的，VFIO 会在 /dev/vfio/ 目录下暴露一些设备节点给 QEMU 使用。在热升级框架中，引入了一个用户态的 VFIO 连接器，它将所有与 VFIO 相关的文件描述符和接口（包括 /dev/vfio、/dev/vfio/grp*、 VFIO eventfd 和 KVM irqfd 等），以及 QEMU 对 VFIO 文件描述符的访问包装起来，如下图所示。在热升级的过程中，只需要将 VFIO 连接器的控制权移交给升级后的 QEMU 进程即可，避免了设备状态的保存和 IOMMU 重映射表的重建等非常复杂的操作。在热升级框架的设计中，我们通过在设备移交后立刻给虚拟机注入一个虚拟中断的方式，解决了中断丢失的问题。

🚀 VFIO（Virtual Function I/O）是一个可以将设备 I/O、中断和 DMA 等能力安全的暴露到用户态空间，从而使用用户态驱动实现设备驱动的框架。通过 VFIO 进行设备直通到虚拟机，可以获得更高的设备 I/O 性能。

在一些典型的测试案例（如 空载、Web 服务器、MySQL 数据库服务器、SPECCPU 压测 等）中，阿里云虚拟机热升级带来的业务中断时间为 30 毫秒左右。该热升级框架在线上大规模虚拟机的功能迭代、运维升级中发挥了巨大的作用，已经成为阿里云弹性计算升级迭代的运维利器，也是阿里云虚拟化的核心技术之一。