2026 年 2 月，AWS 正式宣布在特定虚拟化实例上支持嵌套虚拟化，标志着云计算虚拟化架构的重要演进。此前，嵌套虚拟化仅在 EC2 裸机实例上可用，如今扩展至第 8 代 Intel 实例（c8i、m8i、r8i 等），为微虚拟机（如 Firecracker）、CI/CD 测试环境、网络模拟等场景提供了更灵活且经济的选择。这一变化背后，是 AWS Nitro 系统硬件辅助虚拟化技术的成熟，特别是基于 KVM 的最小化 hypervisor 与专用硬件卡的协同设计。
Nitro 架构演进：从裸机到虚拟化实例的嵌套支持
AWS Nitro 系统的核心创新在于将传统 hypervisor 的功能卸载到专用硬件。Nitro 卡负责网络、存储和安全功能，而基于 KVM 的 hypervisor 仅保留最少的 CPU 和内存虚拟化职责。这种架构使得嵌套虚拟化在裸机实例上自然可行 —— 客户操作系统直接访问底层硬件，可自行安装 KVM、Xen 或 ESXi 并启用嵌套。
然而，在标准虚拟化实例上实现嵌套虚拟化面临更大挑战。传统上，AWS 不向客户机暴露硬件虚拟化扩展（Intel VT-x/AMD-V），以防止资源冲突和安全风险。2026 年的更新改变了这一局面：通过限制支持范围至特定实例类型（第 8 代 Intel），并利用微架构级别的硬件特性（如 VMCS shadowing），AWS 在保持隔离性的同时开启了嵌套虚拟化的大门。值得注意的是，启用嵌套虚拟化时，虚拟安全模式（VSM）会自动禁用，这反映了安全与功能之间的权衡。
硬件辅助资源隔离机制
嵌套虚拟化的性能瓶颈主要来自频繁的虚拟机退出（VM-exit）和上下文切换。AWS Nitro 通过两项关键硬件特性缓解这一问题：
VMCS shadowing 允许 L1 hypervisor（客户机内的 KVM）操作一个 “影子” VMCS，而硬件维护真实的 VMCS 结构。当 L2 虚拟机（嵌套在客户机内的虚拟机）执行 VMREAD/VMWRITE 指令时，无需陷入到 L0（Nitro hypervisor），显著减少了陷阱开销。据研究，未优化的嵌套虚拟化可能将超过一半的执行时间花费在陷阱处理上，而 VMCS shadowing 可将 VM-exit 率降低 30-50%。
Posted interrupts 则优化中断投递路径。传统嵌套虚拟化中，中断需要依次经过 L0、L1 才能到达 L2，引入额外延迟。Posted interrupts 允许中断通过硬件直接投递到目标 vCPU 的 posted-interrupt 描述符，避免多次退出。这对于计时器中断和处理器间中断（IPI）密集的工作负载尤为重要，可降低中断延迟 40-60%。
此外，Nitro 卡的硬件隔离机制确保了资源边界。Annapurna ASIC 和 Nitro 卡管理网络、存储和安全功能，客户机无法直接编程这些硬件，从而维持了多租户环境下的安全隔离。
性能迁移开销分析与可观测性指标
嵌套虚拟化的性能开销因工作负载而异，通常在 5-15% 之间。CPU 密集型任务受影响较小，而 I/O 密集型任务可能面临更高开销。为有效监控和优化，需要设计多层次的可观测性指标：
底层硬件指标
- VM-exit/entry 率：监控 L2 虚拟机的退出和进入频率，理想情况下应显著低于未启用硬件加速的场景。
- VM-exit 平均耗时：测量每次退出消耗的 CPU 周期，VMCS shadowing 应将其从数千周期降至数百周期。
- 中断投递延迟：特别是计时器中断和 IPI 从主机到 L2 的延迟，posted interrupts 应将其从微秒级降至纳秒级。
系统级指标
- CPU 利用率分布：区分时间花费在 L0（Nitro）、L1（客户机 hypervisor）和 L2（嵌套虚拟机）的比例。
- 缓存与 TLB 效率：监控因嵌套层级增加导致的缓存污染和 TLB 未命中率上升。
- I/O 吞吐量与延迟：网络和存储性能相对于非嵌套环境的退化程度。
应用级指标
- 请求处理延迟：对于微服务或 API 服务器，端到端延迟的增加。
- 任务完成时间：CI/CD 流水线或批处理作业的总体执行时间变化。
这些指标可通过 KVM 的嵌套虚拟化统计接口、Linux perf 工具以及自定义的监控代理收集。例如，KVM 提供了嵌套 VM-exit 计数器、shadow VMCS 命中 / 未命中统计等数据。
调度策略与生产部署参数
基于上述分析，提出以下调度策略和部署建议：
实例选择策略
- 工作负载匹配：对于 Firecracker 等微虚拟机场景，选择 c8i.4xlarge 或 m8i.4xlarge 实例，平衡成本与性能。
- 避免混部敏感负载：由于 VSM 自动禁用，安全敏感工作负载应部署在未启用嵌套虚拟化的实例上。
- 预留容量规划：嵌套虚拟化增加内存和 CPU 开销，建议预留 10-20% 的额外资源。
监控配置清单
- 启用详细指标：在客户机内核中启用 KVM 调试统计（
kvm.debug=1）并导出至监控系统。 - 设置基线阈值：针对关键指标（如 VM-exit 率 > 1000 / 秒、中断延迟 > 50μs）设置告警。
- 定期性能剖析：每周运行一次微基准测试，跟踪性能趋势和退化。
优化参数调优
- CPU 亲和性设置：将 L1 和 L2 虚拟机的 vCPU 绑定到同一物理核心，减少跨核通信开销。
- 内存大页配置：使用 1GB 大页减少嵌套层级的页表遍历开销。
- 中断亲和性调整：将设备中断导向与嵌套虚拟机 vCPU 相同的物理 CPU，利用 posted interrupts 优化。
故障排查指南
- 性能下降：检查 VM-exit 率是否异常升高，可能指示 shadow VMCS 未正确启用。
- 网络延迟：验证是否因嵌套导致网络数据包额外复制，考虑启用 SR-IOV 直通。
- 启动失败：确认实例类型支持嵌套虚拟化，且已禁用 VSM 相关功能。
未来展望与挑战
AWS 嵌套虚拟化的支持仍处于早期阶段，仅限特定实例类型和区域。随着硬件迭代和软件优化，预计将扩展至更多实例家族和 AMD 平台。然而，挑战依然存在：安全隔离的强化、实时迁移的支持、以及更细粒度的资源控制都是未来需要解决的问题。
对于工程团队而言，嵌套虚拟化提供了在云环境中构建多层隔离架构的新可能，但需要谨慎评估性能开销、安全影响和运维复杂度。通过系统的可观测性设计和参数调优，可以在功能与性能之间找到最佳平衡点。
参考资料
- Hacker News 讨论："AWS Adds support for nested virtualization"（2026 年 2 月）
- AWS 示例代码库：aws-samples/aws-bare-metal-kvm-demo
本文基于公开技术文档和社区讨论，部署前请参考 AWS 官方文档最新版本。