虚拟化系统
虚拟化解决的核心问题是：一台物理机，如何同时安全地运行多个互相隔离的系统？
1998 年，VMware 用纯软件的方式在 x86 上实现了这件事，让”一台服务器跑多个操作系统”从实验室走进了数据中心。2006 年，Intel VT-x 把硬件支持直接烧进了 CPU，Hypervisor 的性能损耗从不可接受变成了可以忽略。再往后，Amazon EC2 把虚拟化变成了按需出售的商品，彻底改变了软件部署的经济学。
容器的崛起让很多人以为虚拟化要消亡，但事实相反：今天每一个 AWS EC2 实例、每一个 GCP 虚拟机背后都有 Hypervisor 在运行。变化的不是虚拟化存不存在，而是它从工程师每天直接操作的工具，变成了基础设施的隐形地基——越来越薄，越来越专用，越来越不可见。
这个系列从虚拟化的硬件原理出发，经过 KVM/QEMU 的 Linux 实现，到 MicroVM 与容器融合的新范式，最终落在云时代虚拟化演进的时代坐标上。
一、目录
本系列共 4 篇文章，覆盖虚拟化的原理基础、主流实现、容器融合、以及云时代的范式演进。
30-virtualization/
├── 00-virtualization-MOC.md ← 本文件
│
├── 01-虚拟化原理：Hypervisor 如何欺骗硬件.md ← 特权级压缩 / VT-x / Type 1 vs Type 2
├── 02-KVM 与 QEMU：Linux 内核里的 Hypervisor.md ← KVM 模块 / QEMU 设备模拟 / Proxmox
├── 03-MicroVM 与安全容器：虚拟化与容器的融合.md ← Kata / Firecracker / gVisor / 新范式
└── 04-云时代的虚拟化：从 EC2 到 Nitro 的范式演进.md ← Nitro 卸载 / Confidential Computing / 未来方向概念线索
线索一：隔离是需求，虚拟化是手段
多租户安全隔离是一个永恒需求。进程隔离（OS 级）、容器隔离（namespace/cgroups）、虚拟机隔离（Hypervisor）、物理机隔离——四个层次对应四种强度的信任边界。容器不能替代虚拟机，是因为它们解决的是不同强度的隔离需求：容器共享内核，虚拟机有独立内核，Hypervisor 是更深层的安全边界。
贯穿文章：01-虚拟化原理 → 03-MicroVM 与安全容器 → 04-云时代的虚拟化
线索二：性能开销决定了虚拟化能走多远
早期的纯软件虚拟化（VMware 在 x86 上的二进制翻译）性能损耗高达 20-40%，这是”虚拟化用于生产”的最大障碍。Intel VT-x / AMD-V 把硬件级支持加入 CPU，把损耗压到了 2-5%。AWS Nitro 把网络、存储的虚拟化逻辑卸载到专用芯片，让 Hypervisor 开销趋近于零。每一次虚拟化的扩张，背后都有一次性能问题的突破。
贯穿文章：01-虚拟化原理 → 02-KVM 与 QEMU → 04-云时代的虚拟化
线索三：Hypervisor 在下沉，不在消亡
从软件 Hypervisor（VMware ESXi）到内核模块（KVM）到专用硬件（AWS Nitro ASIC），虚拟化的实现层在持续下沉。工程师直接面对的抽象层从”虚拟机”变成了”容器”，但底层的安全边界没有消失，只是变得不可见。MicroVM（Firecracker）是这个趋势的当前形态：以 VM 的安全边界，提供接近容器的启动速度和资源开销。
贯穿文章：02-KVM 与 QEMU → 03-MicroVM 与安全容器 → 04-云时代的虚拟化
线索四：容器与 VM 的融合而非对立
容器的问题在于：共享宿主机内核意味着内核漏洞可以跨租户逃逸。安全要求高的场景（公有云多租户、金融合规、政府系统）需要更强的隔离。Kata Containers 用轻量 VM 跑容器，对上暴露标准 OCI 接口，对下用 KVM 做隔离。Firecracker 把 VM 的启动时间压到 125ms 以内，让”每个函数一个 VM”变成可行。容器和虚拟化不是替代关系，而是在安全隔离和运行效率之间选择不同的平衡点。
贯穿文章：03-MicroVM 与安全容器 → 04-云时代的虚拟化
线索五：信任边界在哪里，虚拟化就在哪里
Confidential Computing（机密计算）是虚拟化下一个前沿：在 CPU 内部构造可信执行环境（TEE），即使云服务商也无法访问租户的内存数据。Intel TDX / AMD SEV 把信任边界从”物理机”缩小到”CPU 芯片内”，是虚拟化哲学的最新延伸——信任的边界在哪里，隔离技术就跟到哪里。
贯穿文章：04-云时代的虚拟化
文章系列
原理基础
核心问题：CPU 是怎么被”骗”成以为自己在独占运行一个完整系统的？
- 01-虚拟化原理：Hypervisor 如何欺骗硬件 x86 的四个特权级（Ring 0-3）与虚拟化的冲突，早期的二进制翻译方案，Intel VT-x / AMD-V 把硬件支持烧进 CPU，内存虚拟化（EPT / Shadow Page Table），I/O 虚拟化（设备模拟 vs SR-IOV），Type 1（裸金属 Hypervisor）与 Type 2（托管 Hypervisor）的本质差异。
Linux 实现
核心问题：Linux 是怎么把 Hypervisor 做进内核的？KVM 和 QEMU 各自负责什么？
- 02-KVM 与 QEMU：Linux 内核里的 Hypervisor KVM 作为内核模块的职责边界（CPU 和内存虚拟化，依赖 VT-x），QEMU 作为用户态进程的职责边界（设备模拟、I/O 处理），两者的协作模型，libvirt 作为统一管理抽象层，Proxmox VE 在 homelab 和企业环境的定位，virsh 常用操作，KVM 与 VMware ESXi 的场景对比。
容器融合
核心问题：容器安全边界不够用的时候，MicroVM 如何填补这个缺口？
- 03-MicroVM 与安全容器：虚拟化与容器的融合 容器的安全边界问题（共享内核意味着内核漏洞可逃逸），Kata Containers（用轻量 VM 跑 OCI 容器），Firecracker（AWS Lambda 背后：125ms 启动，< 5MB 内存开销），gVisor（用户态内核拦截系统调用），三种方案的安全模型对比，“VM 接口 + 容器体验”成为多租户安全计算的新范式。
时代坐标
核心问题：虚拟化在云时代经历了什么变化？社区对这件事的当前态度是什么？
- 04-云时代的虚拟化：从 EC2 到 Nitro 的范式演进 AWS EC2 早期用 Xen，后来迁移到 KVM 的原因，AWS Nitro System（把网络、存储、安全监控卸载到专用 ASIC，让 Hypervisor 开销趋近于零），GCP 的 gVisor 在 Google Cloud Run 上的应用，社区当前态度（VM 没死，变薄了、专用化了），未来方向：Confidential Computing（Intel TDX / AMD SEV），Unikernel 的小众复兴，WASM 作为新的轻量隔离单元。
阅读路径
路径一：从零理解虚拟化
01（硬件原理，建立基础模型）
→ 02（KVM/QEMU，最主流的 Linux 实现）
→ 03（MicroVM，现代融合范式）
→ 04（云时代演进，时代坐标）路径二：理解云基础设施
04（云时代的虚拟化，先建立全局视角）
→ 01（虚拟化原理，理解底层机制）
→ 03（MicroVM，理解 Serverless 背后的隔离方案）路径三：容器安全方向
03（MicroVM 与安全容器，核心）
→ 01（虚拟化原理，理解安全边界来自哪里）
→ 04（云时代演进，Confidential Computing 方向）与其他系列的关联
- 00-hardware-MOC — VT-x / AMD-V 是 CPU 硬件对虚拟化的支持，理解虚拟化原理必须先理解特权级
- 00-linux-MOC — KVM 是 Linux 内核模块，namespace/cgroups 是容器的内核基础，两者共享内核层
- 00-platform-MOC — 容器（Docker/OCI）和 K8s 是虚拟化上层的编排抽象，Kata Containers 是两者的融合点
- 00-security-MOC — Confidential Computing / TEE 是虚拟化的安全前沿，与零信任架构的硬件根基相关
暂存内容
以下文件为原有笔记，内容已被新系列覆盖，后续整理时移除：
01-虚拟化概述.md— 内容被 01-虚拟化原理 覆盖02-虚拟化平台简介.md— 内容被 02-KVM 与 QEMU 覆盖03-KVM概述.md— 内容被 02-KVM 与 QEMU 覆盖04-KVM管理工具.md— 操作手册类，弃用05-KVM网络配置.md— 操作手册类，弃用06-KVM存储管理.md— 操作手册类，弃用07-KVM性能优化.md— 操作手册类，弃用08-KVM系统监控.md— 操作手册类，弃用