背景
作为云计算最重要的底层基础之一,KVM 虚拟化软件在现代的数据中心中应用非常广泛。基于 KVM 的 hypervisor 包括了构成宿主机的软硬件,共同为虚拟机中的应用程序提供高性能的 CPU、内存和 IO 设备等资源。在大规模部署的生产环境中,作为云服务提供商(Cloud Service Provider),如何从技术上保证软硬件的可运维性,一直是大家重点关注的问题。
为了给用户提供稳定、安全、高效并且功能丰富的云资源,IaaS 的底层软件必须能够支撑软硬件的各种运维需求。例如,在偶然出现一些难以避免的硬件故障时,需要能够把虚拟机及时热迁移到健康的宿主机;或者,在软件安全漏洞或功能缺陷被修复后,能够通过热升级,及时部署上线到生产环境中。
然而实现用户无感知地热迁移和热升级,却是一个复杂的系统工程问题。因为 KVM 虚拟化涉及众多不同层次的组件、诸多特性和灵活可选的组合方式,其中不乏一些非常复杂的软硬件技术例如 SR-IOV、Linux内核、QEMU、DPDK、KubeVirt 或者 OpenStack 等,系统总体架构复杂度很高。而且这些软硬件模块各自都有复杂的接口和内部状态,在不影响虚拟机正常运行的情况下,要做到宿主机软件的热升级和热迁移,还需要做一些针对性的设计或改造。同时,作为云计算底座的一部分,它们也需要紧密地配合才能完成预期的功能。特别是对于内部状态处理能力要求非常高的热升级功能,更需要深入、全面的打通。
目前,在各个开源社区(如 Linux,QEMU,CloudHypervisor 等)和各大云计算公司,都在积极地尝试对 KVM 的热升级支持进行研发,也是历年各大技术峰会的一个重要研讨主题。字节跳动技术团队从实际场景出发,相应地对热升级问题进行了深入分析,与开源社区紧密合作,从多个角度做出了深度探索并取得了进展。
在今年 9 月份举行的虚拟化领域全球技术峰会 KVM Forum上,字节跳动系统技术与工程团队 (System Technologies&Engineering,简称STE团队 )公布了相关的技术成果:首次提出一种在KVM热升级场景中透明支持 PCI 直通设备的方案,能够显著降低内核热升级的实现成本 。通过对 host 内核和 QEMU 的扩展和改进,可以做到不依赖于特定硬件修改或者 guest 配合的热升级,支持 PCI 直通设备。同时,在性能方面,也通过深入的分析和优化,将一次内核热升级所需的最少时间(downtime)从 1000ms 降低至 160ms,效率提升 5.25 倍 。
本文将整理回顾 KVM Forum 大会中分享的主要技术方案,以飨读者。
-
KVM Forum 会议演讲视频链接:
Preserving IOMMU States During Kexec Reboot:
文件分享
资料直通车:Linux内核源码技术学习路线+视频教程内核源码
IOMMU状态保持
PCI 设备直通在当前数据中心的 KVM 虚拟化场景中广泛应用,能够为虚拟机中的应用提供高性能的 IO 设备。同时,直通设备的使用也为云计算底层软件设施的运维带来了一些复杂度。
其中,对热升级和热迁移的兼容性是 PCI 直通设备的一大难点。这是因为热升级或热迁移操作依赖于对虚拟机状态的提取、保持、传输等操作,而 PCI 直通设备的状态数据对于宿主机侧的 hypervisor 是不透明的。因此在 IaaS 的实践中,往往需要对使用了直通设备的虚拟机进行特殊处理。例如,通过定制的 SR-IOV 硬件,实现 PF 管理 VF 状态的逻辑;或者在虚拟机中运行特殊的驱动程序和 agent 进程,通过 guest 在过程中的协同配合来完成热迁移或热升级操作。
这些方法可以在一定程度上解决 PCI 直通设备的运维难题,但是带来了更高的研发成本、软件和配置的复杂度,也有可能会牺牲用户体验和 IO 性能。
技术方案调研
在 KVM 中对 PCI 设备的直通需要通过 VFIO-PCI 接口来完成。VFIO-PCI 是 Linux 内核对 IOMMU 和 PCI 底层逻辑的抽象封装 API,提供给运行在用户态的 QEMU 或者其它 VMM(Virtual Machine Manager)软件来配置虚拟设备的 IO 映射关系,从而允许虚拟机内核驱动直接访问硬件资源,以达到较高的 IO 效率。
在热升级过程中,虚拟机的运行状态需要被稳定地保持在升级之前的状态,其中包括虚拟机的 CPU 状态(寄存器里的数据等)、内存数据、虚拟设备的接口状态和内部状态等。对于 PCI 直通设备来说,有2个思路:
- 设法提取设备的状态数据,备份在预先设计好的位置(如预留的内存或者磁盘),然后在热升级结束之前,从备份中恢复。提取备份的过程,一般称之为序列化;从数据中恢复状态的过程称之为反序列化。
- 不提取设备状态数据,并在热升级过程中完全不改变设备状态。热升级完成后,虚拟机继续访问这个硬件设备。
前一种思路已经被证明是可行的方案,并且在某些较新的硬件中已实现,它的优点是不仅可以用来热升级,也可以用来热迁移。在热迁移过程中,虚拟机会被转移到不同的物理机上,也就不可能再使用同一个设备。但是,这个方式的缺点是必须有硬件支持,同时因为存在序列化、反序列化的操作,完成热升级所需时间较长。
我们对第二种情况进行调研和实验后发现,通过对 Linux 内核进行一些局部的修改,在 Intel IOMMU 上可以实现在热升级过程中,设备状态的完全隔离和保护,从而得到一个 PCI 透传设备的热升级通用支持方法。
解决方案
本文提出的方案主要包括三个部分。
改进一**:通过在 hypervisor 中引入必要的静态页面分配,保证 kexec 重启过程中的状态保持。
静态分配主要有用户态和内核态两部分工作。其中,用户态的工作方式为:
- 虚拟机的 RAM 使用 memmap 方式分配,在 host 侧使用 DAX 的形式管理。memmap 是一个内核参数,可以为物理内存分配不同的属性。其中 E820 type 12是一个 NVDIMM 类型(例如 memmap = 2G!6G)。
- 这个类型的物理页,将不再被内核动态管理,而是作为“非易失性内存”来看待。在启动后,我们可以通过创建一个 DevDax 字符设备,mmap 到 QEMU 的地址空间。
- DevDax 的创建可以使用系统调用,也可以用 ndctl 命令:
ndctl create-namespace -m devdax
- 该命令会创建一个类似 /dev/dax1.0 的字符设备。这个字符设备提供一个支持DAX(Linux内核提供的直接物理地址访问机制)的 mmap 接口,可以直接将物理内存映射到 QEMU 用户态。QEMU 命令行参数如下:
$qemu ... -object memory-backend-file,id=mem,size=2G,mem-path=/dev/dax1.0,share=on,align=2M \-numa node,memdev=mem
- 而后 QEMU 会通过 KVM 接口把这段预留内存用于填充 EPT 页表。
改进二:内核态的静态分配实现需要通过一个内核补丁来实现
**
**
- 我们在内核中引入了一个新的物理页管理器 KRAM,为其它模块提供2个分配页的函数接口。这两个接口的主要目的是提供静态物理页给硬件相关模块。
- kram_get_fixed_page(area, index)
- kram_alloc_page()
- 在 E820 的 enum 中定义新的 type 用以预留物理页给 KRAM:memmap=:
- 在 Intel 的 IOMMU 驱动模块中,使用 kram 接口来分配 root page 和 DMAR page。包括iommu_alloc_root_entry和alloc_pgtable_page等函数中,将原本的alloc_pgtable_page替换成对 KRAM 模块的调用。
改进三:对VFIO设备简化,保证硬件状态不被干扰
在VFIO-PCI相关系统调用(VFIO_GROUP_SET_FLAGS)中,我们加入了一个新的标志位,用以在 QEMU 热升级过程中,跳过对VFIO-PCI设备的初始化和重置。
第二、三部分的相关代码将会在后续开源。
POC验证
目前我们在 QEMU 模拟环境中对上面的方案进行了实验。借助 KVM 在 Intel CPU上的嵌套虚拟化支持,和 QEMU 对虚拟 IOMMU 的支持,可以很快的启动一个测试环境:
$qemu -machine q35 -device intel-iommu,intremap=on-cpuhost\... -device e1000e,netdev=guestnet
上面的命令启动的嵌套虚拟化的 L1,运行的是增加了 VFIO-PCI 热升级的内核。对 L1里安装的 QEMU 同样也加入了 CPR(Checkpoint Restore)和 VFIO-PCI 的扩展调用。
使用 VFIO-PCI 我们分配上面的虚拟 e1000e 网卡给 L2:
$qemu ... -device vfio-pci,addr=06.0,host={dev}
然后,通过 cpr-save -> kexec -> 启动qemu -> restore 的流程来热升级整个 L1。
在测试过程中采集到的时间记录如下:
从暂停虚拟机,到重启以后虚拟机恢复运行并在虚拟网络上继续发包,一共经过了 159ms。虚拟 e1000 网卡在这个过程中没有被 reset,始终保持运行状态。也就是说从外部或者应用视角来看,因宿主机热升级而导致的总响应时间,仅仅增加了不到 160ms 的时长,并且由于网卡的 rx 队列始终可用,在流量较低的情况下,也不会导致丢包和重传。相比之下,如果用内核和 QEMU 的主线版本来执行上面的流程,可以采用 savevm 到磁盘后 kexec 重启并 loadvm 的步骤。但是这样不仅不能支持VFIO-PCI设备,也会因为缺少各种优化(如:savevm/loadvm 需要复制虚拟机内存),产生 1000ms 以上的 downtime 延迟。
结论
在使用 VFIO-PCI 透传设备的宿主机上,部署了具有上述改进的 host 内核和 QEMU 等程序。在测试中,基于 QEMU 通用的 checkpointing and recovery(CPR)框架,我们现可以支持低损耗的 host 内核热升级动作。从暂停虚拟机,到重启进入新内核并继续执行虚拟机,整个过程可在 160ms 左右完成。
此技术方案可被应用在公有云和私有云的 IaaS 业务场景,具有很高的实用价值,能够显著降低运维成本,提高云的安全性,并优化运维过程中的虚拟机运行性能和客户体验。字节跳动系统与技术工程团队将会继续优化 Linux 内核和虚拟化软件,为数据中心持续提供安全、稳定、高效运行的系统软件。
此外,在 Virtio 设备标准,QEMU 热升级,Linux 启动时间,io_uring,kexec 等方面,团队也进行了深入的研究和优化。我们将会在本文和后续文章中持续分享相关技术和最新进展。