虚拟化入门

1 虚拟化回答什么问题：一台物理机如何安全地变成多台逻辑机

在 C2 中，我们把云资源放进了机房、可用区与地域。本课把视角缩到机架上的 1 台服务器：它有处理器、内存、磁盘和网卡，为什么能同时交付多台各自运行操作系统的云主机？关键在虚拟化。它把物理资源抽象成软件可见的设备，在多个使用者之间建立隔离，再通过调度复用硬件。抽象、隔离、复用要同时成立；只把应用分成多个目录，并没有得到多台虚拟机。

虚拟机简称 VM。客户操作系统是装在 VM 里的操作系统，它看到自己的处理器、地址空间、启动磁盘与网卡，通常按“我正在管理 1 台机器”的方式运行。真正掌握硬件分配权的是虚拟机监控器，即 Hypervisor。它记录资源归属、安排执行机会，并阻止客户操作系统直接越过边界访问别人的内存。这里的“自己的设备”首先是接口与权限的承诺，不必然表示背后有独占的物理部件。

假设 1 台物理机上的报表服务只在夜间繁忙，另 1 个 Web 服务主要在白天工作。让它们各占 1 台服务器，会留下大量闲置时间。把它们放进不同 VM，可以复用算力，同时保留各自的操作系统、软件版本和维护窗口。但收益来自负载错峰与管理边界，不能推导出“放得越多越省”。如果它们同时忙，调度器仍只能分配现有的硬件时间。

抽象还让机器状态更容易被管理：磁盘可由镜像创建，配置可以记录下来，满足条件时可保存快照或迁移运行位置。这些能力需要存储、网络、处理器兼容性及平台流程配合，并非安装 Hypervisor 就自动全部具备。快照可能只包含磁盘状态，也可能包含内存；没有应用配合的快照，不等于数据库一致性备份。迁移也有收敛、停顿和设备兼容条件。

本课解释云主机背后的基本机制，不进行产品选型。读完后，你应能把“给业务 4 个核”改写成更精确的问题：给的是 4 个可调度的 vCPU，还是承诺独占的物理计算资源；忙时允许等多久；又用什么证据判断平台履行了承诺。

2 Hypervisor 类型：裸金属型与宿主型

Type-1 通常称裸金属型：Hypervisor 直接处在硬件与客户操作系统之间，负责资源控制。Type-2 通常称宿主型：先有桌面或通用宿主操作系统，再由其中的虚拟化软件提供 VM。后者很适合在个人电脑上运行实验环境，因为设备兼容与交互可以借助宿主系统；但宿主上的其他程序、驱动和电源策略也会影响 VM。

这个分类描述的是架构关系，不是“哪个一定快”的排行榜。有些实现把虚拟化能力整合进通用操作系统内核，同时配合管理进程，不能只看有没有管理界面就判断类型。云平台多采用 Type-1 类架构，以便统一管理资源、故障边界和多租户隔离。性能还取决于硬件支持、设备路径、调度策略和具体负载。

在控制台点击创建 VM，首先发生的是控制面工作：核对权限与配额、选择宿主、准备镜像和设备配置，再把创建指令交给对应宿主上的虚拟化组件。VM 启动后，每次 vCPU 获得执行机会由宿主侧调度机制决定，并不是控制台为每条指令发送命令。创建请求成功与业务已经可用也有区别：操作系统启动、初始化配置、服务监听与健康检查都需要时间。

跟随交互观察从镜像到可登录的过程。尤其注意“虚拟磁盘已连接”“客户系统已启动”“业务可用”是不同的完成条件。镜像包含启动所需的系统内容，但不会替你验证业务配置正确。将这几个状态分开，才能在创建失败时判断该检查调度、磁盘准备、启动日志，还是客户系统内部的初始化。

3 CPU 与内存虚拟化直觉：时间片、陷入与超卖

vCPU 是提供给客户系统的逻辑处理器。宿主把它看作需要调度的执行实体，给它分配物理处理器上的运行机会。时间片可以理解为轮流使用机器的短时段：VM 内部觉得线程在持续前进，宿主侧却可能在多个 vCPU 之间切换。当所有 VM 都不忙时，这种轮流使用很难被察觉；当可运行的 vCPU 同时增多，等待就会进入响应时间。

因此，4 vCPU 不等于独占 4 个物理核，也不意味着任意程序都能获得 4 倍速度。单线程任务可能主要使用 1 个 vCPU，存在锁竞争的程序也可能无法有效并行。如果物理处理器启用了同时多线程，宿主显示的逻辑处理器数还可能多于物理核数；这些逻辑处理器共享部分执行资源，不能把数量直接当成同等吞吐能力。本课的算例统一按物理核口径比较。

普通客户程序的许多指令可以借助硬件虚拟化支持直接执行；涉及受控状态或敏感操作时，硬件会把控制权交回 Hypervisor，这常被称为陷入或退出。监控器处理必要的状态检查与模拟后再恢复执行。因此，虚拟化不是逐条翻译所有指令，也不是任何操作都与裸机成本相同。频繁退出、调度切换和虚拟设备交互会增加开销，增加多少必须用实际工作负载测量。

内存也有“看到的地址”与“实际存放位置”的区别。客户系统维护自己的内存映射，虚拟化层配合硬件再把客户物理地址映射到宿主物理内存。VM 可访问的地址必须落在授权范围内，不能因为它知道某个数字地址，就读到另 1 台 VM 的数据。映射与地址转换有成本，缓存和硬件辅助会降低其中一部分，但不会让物理容量变成无限。

超卖是承诺给 VM 的资源总量大于某个物理资源预算。例如 16 个物理核分配 16、32、48、64 个 vCPU，分别形成约 1:1、2:1、3:1、4:1 的数量比。作为教学起点，可以把 16～32 vCPU 视为较保守的试测区间，把 48～64 vCPU 视为更依赖低占空比和错峰的区间；这不是容量保证。即使 1:1，也会受到宿主开销、处理器频率和其他资源瓶颈影响；4:1 在大量空闲开发机上可能可用，在持续计算负载上则很容易排队。

内存超卖通常比 CPU 超卖更敏感。CPU 暂时不够可以轮流执行，活跃内存不够却可能需要回收缓存、压缩或换页，访问延迟可能发生数量级变化。内存气球由客户内的配合驱动占住一部分客户可用内存，让客户操作系统主动回收，再由宿主利用释放出的页。它不是凭空创造内存；回收过度时，客户可能换页，应用缓存也会下降。没有相应驱动、策略或可回收空间，气球就不能按想象工作。

拖动参数时，应区分“配置总量”和“同时活跃需求”。32 个 vCPU 只说明数量比为 2:1；如果高峰同时需要 12 个核，仍可能有余量，如果需要 28 个核，就必须等待。内存也要看工作集、回收能力与保留量。交互只帮助建立方向感，不能输出某个超卖比必然安全的结论。真正的决定依据是峰值、持续时间、延迟目标和故障时的剩余容量。

4 设备与 IO：磁盘、网卡如何被分享

VM 中的磁盘和网卡通常也是虚拟设备。应用写文件，客户系统把请求交给虚拟磁盘驱动，宿主侧后端再把它送往实际存储。应用发送数据，也要经过客户系统、虚拟网卡和宿主侧处理路径，最后由物理设备完成传输。每经过 1 层，都可能发生排队、数据复制、通知或上下文切换。CPU 看起来还有空闲，并不能排除设备路径已拥堵。

如果完全模拟某种传统硬件设备，客户系统可以使用现有驱动，但监控器可能要解释大量设备寄存器操作。virtio 等半虚拟化接口让客户驱动知道自己正在与虚拟设备协作，双方通过约定的队列交换请求，减少不必要的模拟。这里的“半”不是隔离做到一半，而是客户驱动参与了高效接口的实现。镜像缺少合适驱动时，可能出现启动盘不可见、设备不可用或性能不足。

磁盘不能只用容量描述。数据库的小块随机写、日志的持续追加、备份的大块顺序读，会对同一后端提出不同要求。IOPS 表示每秒操作数，吞吐量表示每秒传输量，延迟表示单次请求花费的时间。三者必须结合块大小、读写比例、队列深度观察。吞吐量尚未达到标称上限，也可能因为小 IO 的操作数限制或同步写等待而变慢。

网卡也有带宽、每秒包数和处理开销等维度。大量小包可能先耗尽处理能力，未必先耗尽带宽。中断合并会把多个事件合在一起通知 CPU，以降低通知频率；它通常能减少处理开销，但也可能增加部分请求的等待时间。是否合适取决于吞吐与延迟目标。设备路径的直通机制留到后续专题，本课先掌握请求经过哪些层、在哪里排队以及如何用指标定位。

5 隔离、吵闹邻居与性能可预期性

隔离至少有 3 个不同问题：别人能不能读写我的数据；别人的故障会不会影响我；别人繁忙时我还能否得到承诺的性能。VM 的独立客户内核和受控硬件访问提供了较强的执行边界，但这些问题不能用 1 个“已隔离”全部回答。同宿主的 VM 仍可能共享缓存、内存带宽、磁盘后端与物理网卡，宿主故障也可能同时中断多个 VM。

吵闹邻居指共享资源中的某个负载增加，使其他负载的服务质量下降。它不要求邻居有恶意：一次备份、报表扫描或批量日志压缩就可能造成影响。症状可能是业务吞吐下降、尾延迟升高、定时任务超时。平均响应时间变化不大也不能排除问题，因为少量很慢的请求可能已经违反业务目标。

证明“被抢”需要把业务症状与共享层证据放在同一时间轴上。先观察请求量、错误率和延迟分布，再看客户 CPU 的使用率与 steal、运行队列、磁盘队列与延迟，最后在有权限时对照宿主调度等待、后端负载和其他 VM 的活动。客户系统内 CPU 使用率高，可能只是自己的计算需求大；使用率不高但延迟高，也可能是等待外部依赖。单个指标无法自动归因给邻居。

性能可预期性可以通过资源保留、上限、调度权重、负载分组与容量余量改善。保留描述保证得到的资源，上限限制最多消耗多少，权重通常决定发生争用时如何相对分配；这些含义不能互换。把所有 VM 都设为最高权重并不会增加硬件能力。关键服务应明确最低需求和高峰目标，批处理可以通过限速或安排窗口减少同时争用。

容量余量还要覆盖迁移和故障。当多个宿主组成资源池时，平时每台都运行在极限附近，失去 1 台后就可能无处安置剩余工作负载。单机留出 20% 内存并不等于已经具备高可用：是否能在其他宿主恢复、恢复耗时多久、数据是否仍可访问，都需要独立设计和演练。

6 虚拟机与容器：对照一句，边界在哪

VM 通常运行各自的客户内核；容器通常共享宿主内核，利用操作系统提供的进程视图、权限和资源限制形成边界。容器看起来也有自己的文件系统与进程列表，但它没有因此获得独立的客户内核。VM 的边界通常更适合需要不同操作系统内核或较强租户隔离的场景；容器适合以应用交付为中心、希望快速启动和提高部署密度的场景。

这不是绝对安全与不安全的二选一。两者都依赖及时修补、最小权限、镜像来源与正确配置；VM 边界也不能消除 Hypervisor 漏洞。容器还可以运行在 VM 内，让平台用 VM 建立租户或节点边界，再用容器组织应用。此时仍需要为客户系统和容器工作负载共同预留资源，不能把同一份容量在两层都按满额出售。

本课只保留这句选型判断：先明确内核兼容与隔离边界，再比较交付效率和资源成本。容器的部署方式、镜像生命周期与编排留到 C26，当前不必为了理解虚拟化先掌握它们。

7 常见坑：把虚拟化当零开销、超卖当无限、忽略嵌套与许可

第 1 个坑是“有硬件辅助，所以虚拟化无损耗”。硬件辅助降低了很多成本，却没有消除调度等待、设备后端处理与地址转换。性能验收要使用接近业务的请求形态和持续时间，并分别记录吞吐、平均延迟与尾延迟。只测 1 次短跑，可能刚好避开备份窗口、缓存冷启动和持续写入后的变化，不能证明生产高峰稳定。

第 2 个坑是“平时只用 10%，所以能无限超卖”。平均值会隐藏同时高峰。8 个服务各自平均只用 1 个核，可能在整点一起需要 4 个核；内存缓存也可能在运行几小时后才增长。应记录高峰的相关性：它们是否共享任务计划、用户时区或促销事件。超卖比是策略输入，持续负载与延迟目标才是验收条件。没有测量数据时，宁可给试运行设置退出条件，也不要把教学区间写成保证。

第 3 个坑是默认可以在 VM 内再启动 VM。嵌套虚拟化需要平台暴露相应硬件能力，本课方案默认关闭，确有构建或测试需要时再单独验证支持情况。嵌套会增加调度、设备和排障层次，有些迁移与加速能力也可能受限。应用启动失败时，应先确认能力是否暴露，不能仅凭宿主处理器型号判断一定可用。

第 4 个坑是忽略许可和计费边界。某些软件按核、处理器、宿主或部署实例授权，VM 的可见核数未必就是许可核数，迁移还可能改变覆盖范围。应依据具体合同与厂商条款核对，不能把“技术上能启动”当成“许可已经满足”。同时检查镜像使用权、客户操作系统订阅和备份恢复到其他宿主时的约束，把费用放入容量决策。

8 案例：从 1 台物理机规划 8 个业务 VM

现有 1 台服务器，包含 32 个物理核、512 GB 内存。业务需要 2 台数据库 VM、4 台 Web VM、1 台任务 VM 和 1 台运维观测 VM。先声明假设：以下磁盘容量只是规划需求，实际后端是否满足需要另行验收；8 台 VM 运行在同一宿主，无法抵御该宿主故障；没有持续重计算任务，数据库对延迟更敏感。目标是形成可测试的初始方案，而非凭配置表宣布容量充足。

先为宿主与管理组件划出 4 个核的容量预算及 32 GB 内存，再保留 4 个核的容量余量与 96 GB 未分配内存。因此，初始 VM 内存总量控制在 384 GB，持续 CPU 需求预算控制在约 24 个核。这里的“划出核预算”不是已经绑定独占核心；若需要独占或保留保证，还必须配置并验证平台对应机制。宿主开销也需实测，不能永远固定为这个数字。

40 个 vCPU 对 32 个物理核的数量比为 1.25:1，但可持续分给业务的预算只有约 24 个核，因此不能只凭 1.25 就认定安全。试运行可以先假设数据库组高峰合计需要 12 个核，Web 池需要 8 个核，任务需要 2 个核，观测需要 1 个核，总计约 23 个核。这个假设必须通过并发压测与生产样本验证；如果它们同时需要全部 40 个 vCPU，就会排队，必须减载、调整保留或扩容。

系统盘负责启动与基础软件，数据库数据盘承载随机访问，日志盘承载持续写入，工作盘承载可清理的任务中间结果。分盘有助于设置配额、观测与恢复边界，但多个虚拟盘若落在同一拥堵后端，并不会获得真正的物理性能隔离。规划表之外还要写明数据盘与日志盘分别经过什么后端、允许多少 IOPS 与吞吐、同步写延迟目标，以及快照和备份占用什么空间。

初始策略是内存不超卖，数据库设置最低资源保证，Web 池允许共享空闲 CPU，任务 VM 设置消费上限并避开数据库维护窗口。Web 的 4 台实例可以分担单个进程或客户系统故障，却不能因为数量为 4 就声称可以抵御宿主故障。若业务要求宿主失效后继续服务，就需要额外宿主和跨宿主部署，重新计算故障状态下的容量。

验收交付包含 3 部分。资源表要核对总数、保留量、磁盘增长与许可；隔离假设要标出共享宿主、共享存储和可接受的故障范围；监控项要覆盖业务延迟、CPU 等待、活跃内存、换页、存储队列与尾延迟。测试同时运行数据库查询、Web 峰值、任务批次与观测采集，确认关键服务仍满足目标，再记录扩容触发条件。任何 1 项缺失，配置表都还不是完整方案。

9 排查案例：突然变慢、CPU ready 高、盘 IO 抢占

上线后某天 10:00，Web 请求的第 99 百分位延迟从 120 ms 升到 900 ms，平均请求量基本不变。先确认采样窗口、时钟和变更记录，检查是否发布新版本或外部依赖超时，并保留事故前后的指标。不要先重启全部 VM；重启可能清空队列和现场，让问题暂时消失却无法解释原因。接下来沿 3 条路径找证据，每条都包括支持证据、反证和可回退的试验。

路径 A 检查 CPU 调度等待。在可提供相应指标的平台上，CPU ready 描述 vCPU 已可运行却未得到物理执行机会的等待；Linux 客户系统中的 steal% 表示被记账为让给其他执行环境的时间。两者来源、统计口径与可用性不同，不能直接当作同一个数字。某些环境不暴露 steal，因此数值为 0 也不自动证明没有争用。若 ready 是多个 vCPU 的时间累计，先按平台文档换算，再与单核百分比比较。

本次观测到任务批次启动后，多台 Web VM 的 steal 从接近 0 升到约 12%，宿主调度等待也同步增加，Web 内部可运行线程增多；客户系统并没有明显换页。暂停非关键任务 5 分钟后，等待与尾延迟同时回落，构成较强的 CPU 争用证据。后续应限制任务并发、调整保留并重新压测。不能仅因 VM 配了 4 vCPU 就加到 8：增加可调度实体未必增加物理能力，还可能扩大争用。

路径 B 检查磁盘争用。另一次慢请求中 steal 没有明显变化，但数据库写延迟上升，客户与后端队列增长，延迟直方图中超过 20 ms 的请求明显增多。查看后端发现任务 VM 正在扫描并写入同一存储池。此时需要结合请求块大小、读写比例与吞吐看限制在哪里；队列长度变大表明请求在积压，但不能单凭队列长度判定磁盘损坏，允许的并行度也会影响正常队列水平。

对任务写入限速后，数据库长尾收缩，后端队列也回落，说明共享 IO 是主要路径。长期措施可包括独立性能预算、调整后端布局、优化批次窗口或减少不必要写入。只在 VM 中把数据移到另 1 块虚拟盘，如果后端没变，可能毫无改善。也要检查客户系统自身的刷盘周期与存储服务限制，避免把所有排队都归因于邻居。

路径 C 检查网络通知与处理。若 CPU 等待和磁盘指标都稳定，某次驱动更新后小请求的尾延迟却上升，应比较包速率、丢包或重传、软中断处理、接收队列和中断合并配置。较强的合并可能减少中断次数，提高大流量吞吐，却让小包等待更久。它属于设备处理策略的变化，不必然意味着邻居抢占；只有宿主或物理设备的共享证据支持时，才继续归因到共享层。

在低风险窗口恢复已知配置，保持请求大小与并发一致，若延迟直方图改善且 CPU 开销仍在预算内，才把它作为候选修复。不要照搬“关闭合并”作为通用答案，过多中断也可能耗尽 CPU。3 条路径最终都应留下相同结构的记录：何时变慢、哪层等待、哪些指标同步变化、做了什么单变量试验、恢复后是否持续达标。云上看不到宿主时，提交带时间戳的客户指标、延迟分布与对照结果，请平台协助确认共享层证据。

放进方案里

方案首先声明虚拟化假设：业务运行在独立 VM 中，客户操作系统由谁维护，平台提供哪些硬件能力，是否允许迁移。本例默认关闭嵌套虚拟化，内存不超卖；vCPU 是可调度资源，独占或最低保证需单独约定。写清这些前提，可以避免业务把规格数字理解成永久独占的物理部件，也让镜像驱动与软件许可检查有明确责任人。

容量部分同时列配置总量、持续需求和峰值需求。32 核、512 GB 的示例分配 40 vCPU、384 GB 客户内存，另有宿主预算与增长余量，但只有联合负载验收通过后才能接受。超卖策略注明适用负载、争用时的优先级、批处理上限和停止扩张的条件。若高峰相关性或内存工作集尚不明确，先记录为待验证假设，不能用平均利用率代替证据。

隔离部分分别说明数据访问边界、性能边界与故障边界。数据库需要什么最低资源，系统盘、数据盘和日志盘是否共享后端，都要写清。同宿主的多个 VM 不能承担宿主失效后的连续服务承诺；需要此能力时，应补充跨宿主部署与故障后容量。快照、备份及恢复演练各自覆盖什么状态，也应明确，避免把可创建快照等同于可恢复业务。

监控部分把业务尾延迟与 steal、平台调度等待、内存回收、换页、设备队列和延迟直方图关联起来，约定采样窗口、告警持续时间与处理人。阈值通过基线和业务目标确定，争用时先保护关键服务，再按预案限速或迁移。进入 C4 选择云主机规格时，把这里验证过的计算、内存、存储和隔离需求映射到平台承诺，并保留验证记录，作为扩容和成本复盘的依据。

10 小结：走向云服务器（C4）

虚拟化通过抽象、隔离和复用，把物理服务器变成多个可管理的运行环境。vCPU 数量、客户内存与虚拟磁盘容量描述了配置，持续性能还取决于调度、活跃需求和设备路径。资源表要与隔离假设、联合负载测试和监控证据一起交付。

进入 C4 云服务器时，我们会把这些原理转成规格选择与实例使用。先带走 3 个判断：vCPU 是否独占要看承诺；超卖是否可行要看同时高峰；突然变慢要沿等待路径取证。能说清这 3 件事，才有依据比较不同云主机配置。

下一课转向 C4 云服务器：把本章验收过的结论带进后续主题，写成可检查的方案约束。