Guest OS 作为运行在虚拟机云服务器之上的系统软件，是虚拟机云服务器服务的重要组成部分。由于虚拟机云服务器交付给用户的是 “VM 服务”，因此，作为对接用户的 “最后一公里” 的产品，一个优秀的 Guest OS，是保障云服务提供商交付的 “VM 服务” 三大核心竞争优势的重要组成部分。

• 成本效率优势

提供免费使用的 Guest OS 是云上主流用户的诉求。目前云上使用最多的系统之一是由 CentOS 开源社区提供的免费的 Linux 发行版。很多云服务提供商都推出了自有操作系统版本，例如，AWS、阿里云都推出了免费的商业 Linux 发行版，并且有长期稳定版 LTS （Long Term Stable）的维护承诺，以确保云上的用户有比社区免费版本更好的用户体验，保护用户的投资。

Guest OS 必须具有成本优势，而且不能成为提升 VM 交付效率的瓶颈。Guest OS 的效率不仅仅体现在资源交付上，例如，VM 快速启动、秒级交付，在一些容器实例上，通过一些优化技术，甚至可以达到百毫秒级交付；还体现在支持用户业务的生态环境上，操作系统的基础运行环境可以和用户业务无缝集成，保持良好的兼容性，形成端到端的解决方案。

• 稳定性优势

Guest OS 的稳定性不仅体现在可靠性、可用性、可服务性上；更体现在系统安全可靠上。没有 Guest OS 的稳定性，用户就无法得到最终的稳定性，这样虚拟机云服务器的 SLA 就会变得没有价值。

• 性能优势

软硬件一体化、硬件卸载技术，降低虚拟化开销，使得虚拟机的性能逼近物理机的性能，是虚拟机技术发展的主要趋势。好的性能不单单要靠高性能的虚拟机，也要靠高性能的 Guest OS。云服务提供商之间的性能竞争正在成为全栈的竞争，而保持 Guest OS 高性能是其中重要的一环。

所有云服务提供商的虚拟机云服务器都提供多种 Guest OS 供用户选择，其中，Windows 和 Linux 毫无争议地成为两大主流。根据 IDC 数据，在桌面操作系统市场，Windows 操作系统依旧占据霸主地位；然而，在云计算领域，Linux 操作系统占据统治地位，已经是一个事实标准。即使是在微软的 Azure 上，Windows 的份额也有比较显著的下滑。2018 年，微软表示，在 Azure 云上的 VM 中，Linux 操作系统份额已经超过 Windows，并且很多微软 Azure 的云服务产品，例如 SDN，已经运行在 Linux 操作系统上。

1.基础架构

一个完整的 Linux 发行版可以被划分成三大部分，以 Aliyun Linux 为例，如下图所示。

• Kernel 即内核，是操作系统的核心组件，管理软硬件资源，向上通过系统调用，提供面向应用软件操作系统的基本服务，通过进程管理及调度器、内存管理、存储栈、网络栈等子系统来支撑一个操作系统的基础功能。
• Base OS 是操作系统发行版的基础运行环境，取决于操作系统的应用场景，可由数百到数千个软件包组成，为核心应用软件场景提供基础环境，包括容器、语言运行时、开发工具、包管理、镜像管理、系统核心服务等操作系统所需的基础公共功能。
• Application 即应用软件，根据操作系统的应用场景，必然存在一个或者多个核心应用运行在操作系统上，为实际业务提供服务。应用生态的软件包可以是操作系统默认搭载的软件包，也可以是单独发行的第三方软件包；可以是开源软件包，也可以是商业软件包。经过 Linux 发行版和开源社区的多年发展，在服务器操作系统领域，形成了强大的应用生态环境。

2.成本效率优化

2.1 保障兼容性、简化生态环境，解决方案一键部署

操作系统的生态环境非常复杂，而且存在非常大的用户黏性，是操作系统厂商的核心竞争力。整个操作系统的生态环境可以被粗略分为 硬件平台驱动生态 和 应用软件生态。

在云场景下，虚拟机云服务器的虚拟硬件规格更加整齐简单，VM 及相关驱动模块也在海量的部署环境中得到了打磨与验证，因此，传统 IT 基础设施因硬件兼容性问题带来的部署和维护成本问题能够在云上得以根本解决。

应用软件生态是 Guest OS 需要解决的首要问题。由于问题的复杂性及一些历史原因，很难形成统一的云服务器应用软件的标准和规范。即使是 Linux 发行版，操作系统应用软件生态也因为发行版基础运行环境的差异，产生了不同程度的碎片化的事实标准。例如，在软件包管理方式上，存在 RPM 和 DEB 两种事实标准，基础运行环境所包含的应用软件的语言运行环境（Runtime）也会因发行版不同而有所差异，造成预期外的软件兼容性问题。为解决以上问题，云服务提供商一般采用以下三种做法。

• 虚拟机云服务器支持多版本、多厂商的 Guest OS，以满足不同用户和业务的兼容性需求。
• 提供自研的 Guest OS 发行版，提供更佳的硬件兼容性体验，并确保应用软件兼容性符合某种事实标准。例如，Amazon Linux 2、Aliyun Linux 2，都兼容 CentOS 应用生态。
• 发展云市场及应用软件商店，通过虚拟机一体机（VM Appliance）、容器镜像、应用商店的模式，使得云上常见的解决方案可以被一键部署，实现传统服务器 OS 不能达到的部署效率，同时解决了兼容性问题。

2.2 提升资源弹性和资源利用率

云的核心竞争力就是通过资源弹性来获得资源利用率的提升。对于经常需要短时间扩缩容的应用场景，虚拟机云服务器分钟级的弹性部署能力是非常核心的能力，其中，除虚拟机云服务器的资源交付外，Guest OS 的资源交付能力也是重要的一环，因此 Guest OS 的启动性能成为一个重要的能力。

为提升 Guest OS 的启动性能，一系列优化技术得以应用。

• 虚拟机机器模型和固件（Firmware）及内核启动过程的简化。这里涌现出了大量的开源项目，如 Clear Container、Clear Linux、Qemu Lite、Nemu、Qboot，以及 AWS 的 Firecracker 等。通过优化，这些项目将虚拟机和 Guest OS 的启动性能显著提升，在一些场景下，可以达到秒级甚至毫秒级。
• 内核启动过程的优化。在操作系统启动过程中，内核负责系统资源的枚举和初始化。这些枚举和初始化工作可能会有很大的开销。例如，大规格的虚拟机内存初始化占据了大量的时间。因此，推迟内存初始化的技术在大规格实例上有显著的启动性能优势。
• 系统服务的启动优化。通过使用 systemd 服务的并发启动能力，关闭不需要的系统服务，可以实现系统服务的启动优化，systemd 也提供了服务启动的性能分析工具，可以非常方便地找到启动的瓶颈。

除通过 资源弹性供给 提升资源利用率外，在虚拟机内部，Guest OS 还可以通过 容器调度技术，增加应用的部署密度，从而提升虚拟机的资源利用率。

容器调度技术一般通过 分时复用 和 资源互补型业务混部（Co-Location）来提升利用率，这就对 Guest OS 的服务能力了提出新的要求。

2.2.1 系统资源的量化和监控

操作系统内核拥有系统资源实时占用和消耗的数据统计能力，而且长期依赖 Linux 已经形成了一套事实标准，以满足运维需求。然而，随着云原生业务的发展，应用容器化部署已经成为常态，因此更细粒度的、以容器为单位的系统资源统计和量化的能力在一定程度上不能满足容器调度系统对资源调度的需求。

随着 Linux 内核社区的发展，基于 cgroup 的监控特性也在不断完善。例如，Facebook 在 Linux 内核社区提交的 PSI 特性，可以量化和归一化统计 CPU、内存、I/O 等方面的容器压力情况。然而，这些特性离云原生规模化运维系统的需求有很大距离。Aliyun Linux 基于多年容器调度混部的运维经验，提供了更丰富的容器场景的数据化特性，成为一个对容器化运维场景更友好的操作系统。

2.2.2 资源隔离能力

随着服务器硬件能力的提升，单系统 CPU 和内存的密度越来越大，硬件利用率提升逐渐变得重要起来。容器化和混部技术在提高系统资源利用率、应用部署密度的同时，带来了更激烈的资源竞争问题。

Linux 内核主要使用 cgroup 机制来应对资源竞争问题，提供了共享内核、共享资源场景下的资源隔离解决方案。资源隔离能力 是资源利用率和系统性能之间取舍折中的产物。如果没有对高资源利用率的追求，那么当前 Linux 操作系统的资源隔离能力可以满足基本需求。但在高利用率场景下，对于进一步提升资源隔离能力以保障系统 QoS，Linux cgroup 机制还存在很大的不足，主要问题如下。

• 在 CPU QoS 方面，尽管 cgroup 支持 Quota、Share 等 QoS 机制，但在高资源利用率下，核心的问题还是对硬件资源的竞争，以及内核 CFS 调度算法如何同时满足延迟敏感任务和批处理计算任务的需求。内核社区实现了 Intel 提出的 CAT、MBA 等 CPU Cache，内存带宽能隔离机制，谷歌和阿里云还实现了各自定制的调度器算法，以解决高利用率下调度延迟的问题。目前，此方向的技术演进非常快，而且更多的试错还在进行中，并未形成更通用的解决方案。
• 在内存领域，cgroup 机制仅仅实现了按照 cgroup 记账，以及 cgroup 内存资源的使用上限，在 page cache 层面，buddy 子系统、高利用率高压力的并发竞争，还有很多未解决的问题。目前谷歌和阿里都各自实现了有 QoS 差别的主动内存回收算法，以及 per cgroup 的内存回收策略，一定程度上可以缓解内存压力。但是，软件层面的严重共享的底层设计，让内存 QoS 难以得到很好的保障。
• 在存储领域，长期以来，Linux 内核缺乏一个可用于生产环境且具备 QoS 能力的文件系统，只有块设备层实现了基于 cgroup 的 QoS 机制，支持按照带宽、延迟来配置共享磁盘 QoS 策略。在传统物理机环境下，因为磁盘空间和资源有限，在容器共享文件系统时，QoS 的保障问题没有很好的解决方案。在虚拟化云服务器上，由于云盘的使用，避免文件系统共享或者磁盘共享比较容易做到，所以问题迎刃而解。
• 在网络领域，Linux 网络栈 QoS 是基于 TC 模块实现的，并且早于 cgroup 的发展，技术也比较成熟。在容器调度的高利用率的情况下，网络 QoS 的问题通常与其他资源竞争问题交织在一起，例如，CPU 和内存压力经常带来网络延迟的抖动。因此，更好的网络 QoS 方案是全栈和系统化的定制。

3.安全性和稳定性增强

3.1 安全性

由于云基础设施带来的硬件和软件场景的简化，与面向通用场景的操作系统不同，云服务提供商的 Guest OS 可以通过对云场景无关代码的裁剪，减少系统的受攻击面来提升系统的安全性。

在 Guest OS 的生命周期内，厂商也要负责及时提供 CVE 安全预警、修复更新等服务，以确保系统的安全性。

此外，系统的安全性还有赖于正确的系统安全配置，以及系统安全最佳实践的正确应用。例如，AWS 和阿里云都支持 CIS 认证的加固镜像部署，并且提供了符合 CIS 安全规范的配置检测工具，以帮助操作系统管理员确保系统安全得到了正确的配置。

最后，保障云系统安全可信也是一个重要的技术方向。可信 Guest OS 以 TPM 虚拟化技术为基础，通过将信任链从云平台物理机层面传递到 Guest OS 的方式，使用远程证明和本地证明手段检测出系统的关键组件是否遭到了篡改和破坏，同时提供可靠的敏感数据安全防护机制。例如，Aliyun Linux 2 通过实现可信计算模块，满足了等保四级合规的要求，并可以辅助有等保四合规需求的租户通过相关的合规审查。

3.2 RAS

3.2.1 可靠性（Reliability）

主流 Linux 操作系统都提供了错误报告机制，以确保在软硬件故障发生时可以正确地被检测到，并且及时报告，操作系统的错误处理程序会正确地处理错误，以防止出现 数据损坏（Data Corruption）。

Linux 发行版在软件层面的错误处理能力大同小异，目前还存在以下问题。

• 用户往往会忽视通过升级内核提升系统的可靠性。例如，软件缺陷没有及时被修复导致故障，或者对新硬件支持不够，内核不能很好地处理新的硬件型号的 RAS 特性。
• 云服务提供商的服务器或者虚拟化层不支持 RAS 特性，导致 Guest OS 的 RAS 特性无法发挥作用。

在物理服务器内存容量越来越大，大规格虚拟机内存容量越来越大的情况下，Guest OS 的 RAS 能力将会逐渐成为企业级应用的一大痛点。在物理服务器 RAS 特性使能的前提下，通过虚拟化能力的透传，让 Guest OS 可以端到端地处理硬件错误，必然是一个技术趋势。

3.2.2 可用性（Availability）

Guest OS 可用性的核心是减少系统的 非计划停机时间（Unplanned Down Time）。系统可以在操作系统的软件层之上，使用高可用方案保障业务的连续性，减少系统不可用时间对业务可用性的影响。然而，Guest OS 对故障检测和 Failover 过程更友好的支持，可以大大提升云上 Scale Out 系统的运维效率。

系统不可用可能有很多原因，从错误现象上分为以下三类。

• 宕机（Panic）：内核检测到软件或硬件错误，进入 kernel panic 流程，然后重启恢复服务。这时，系统的恢复时间和 panic 流程里 crashdump 的性能、启动性能都有关系。
• 夯机（Hang）：内核全局夯死。这时软件可以通过网络心跳，或者设置内核看门狗（Hard/Soft Lockup Watchdog）等手段检测到夯机。此时可以触发应用层的 failover，并触发 kernel panic 来保障夯机原因得到诊断。
• 任务夯（Task Hang）：关键进程在内核卡死或者卡顿超时。这时软件可以通过内核看门狗（Hang Task Detector）检测到任务夯，此时可以触发应用层的 failover，并触发 kernel panic 来保障任务夯原因得到诊断。

3.2.3 可服务性（Supportability）

Guest OS 可服务性的主要目的是提升 Guest OS 维护的效率，降低 Guest OS 维护的成本。无论用户使用的是 Scale Up 架构，还是 Scale Out 架构，在操作系统发生故障时，都可能产生故障修复或者至少是根本原因分析的诉求，这方面的能力甚至会直接影响到用户和服务商根据 SLA 定责的公平性和效率。

如前所述，当系统不可用时，不论是宕机、夯机、关键任务夯都可能会触发 kernel panic 来辅助故障修复和诊断分析，而在这个过程中，如何比较可靠地产生 kernel core dump （内核核心转储）文件，成为焦点问题。这里主要的问题有以下几种。

• 需要人工干预。夯机自动检测设置较复杂且有很多原因会导致失败，因此需要人工干预。例如，AWS 通过支持用户主动触发 kernel core dump 帮助诊断系统问题。
• 需要避免内存浪费。Linux 内核 kernel dump 机制可能造成预留内存浪费问题，因此需要支持其他 kernel dump 机制。例如，允许将 kernel core 直接保存到用户指定的对象存储空间中。
• 需要提升 kernel dump 性能。kernel dump 会导致系统冻结，造成短时间内系统不可用，需要提升 dump 性能，缩短系统不可用的时间。

除可用性故障外，还有很多 Guest OS 故障与服务质量相关。比较常见的性能抖动问题、系统资源竞争问题都需要更高效率的故障诊断和界定工具来帮助确定原因。例如，当应用对文件的 buffer I/O 的写出现抖动时，究竟是 Guest OS 的内存压力问题，还是文件 I/O 系统的锁问题，抑或是底层云盘块存储的问题呢？

现代内核支持动态追踪技术的 Linux 发行版，可以方便安全地使用 eBPF 追踪技术快速定位上述问题。例如， Aliyun Linux 2 的发行版集成了基于 eBPF 的诊断工具包，这些工具包也是阿里云内部规模化运维诊断系统问题多年的经验积累。

4.性能优化

4.1 全栈优化

由于 Guest OS 运行在虚拟机上，所以虚拟化的性能开销是虚拟机性能的一大制约，常见优化如下。

• 通过优化 Guest OS 内部的时钟、外设中断、特殊指令提升性能。这里以 Aliyun Linux 2 的优化案例为例。
  • 网络协议栈使用 BBR 流控协议，而 BBR 频繁使用时钟中断导致大量的 VM_Exit。
  • HLT 指令引发不必要的 VM_Exit，使用 halt polling 优化性能。
  • 避免监控工具和脚本触发 MSR 寄存器读写，高频 IPI 中断，导致大量 VM_Exit。
• 通过 PV 半虚拟化方式实现 Guest OS 和 Host OS 协同优化。

多线程 TLB IPI 经常引发频繁 VM_Exit 导致的性能问题，通过云平台和 Guest OS 协同，引入 PV IPI 机制，极大降低了 IPI 导致的性能开销。

正处于活跃开发状态的 Virtiofs 也提供了一个高性能的虚拟机之间共享文件的机制。对购买虚拟机搭建自有 PaaS 容器平台的用户而言，这是一个不错的应用场景。

4.2 解决方案优化

在云上构建贴近用户的端到端解决方案，通过 Guest OS 及云全栈优化构建最优解决方案，是未来企业级用户上云的重要诉求。

云服务提供商的 Guest OS 通过发展 ISV 和解决方案合作伙伴，帮助第三方软件按最优的性能服务于用户。用户可以在云市场部署和运行经过验证的、成熟的解决方案。

例如，OceanBase 数据库在阿里云使用了 204 台安装有 Aliyun Linux 2 的 i2 规格族的 ECS 实例，第一次基于云的架构实现了性能最好的 OLTP 类型的数据库解决方案，并通过了 TPCC 测试。

一旦云服务提供商 Guest OS 与其他云产品形成可复制的解决方案，云服务提供商就可以通过 Linux 发行版的形式集成部署解决方案，或者在云市场使用虚拟机镜像的分发的形式，形成可一键部署的解决方案，提升用户体验和方案部署效率。

总之，随着操作系统开源技术的演进，云上 Guest OS 必然会形成以 Linux 开源社区为事实标准的生态环境。通过服务器硬件、虚拟化基础设施、Guest OS 的协同配合，云基础设施计算资源的交付成本效率、稳定性、性能都会得到持续的改进和升级。