📚 课程目录第2章多OS基础概念

2. 多OS基础概念

在讨论多OS CPU内存与设备资源规划之前，必须先厘清一组最基础、也最容易被混用的概念：操作系统类型、虚拟化与容器化的差异、Hypervisor 的定位，以及 Guest OS 与 Host OS 的关系。这些概念决定了后续资源如何切分、如何隔离、如何被调度，也决定了容量规划时应该看哪一层指标。

一、操作系统类型：从裸机到多OS共存

操作系统按运行位置与用途，可以粗略分为三类：

裸机操作系统（Bare-metal OS）：直接运行在物理硬件之上，独占 CPU、内存、磁盘与网卡，例如传统 Linux 发行版、Windows Server。它没有下层宿主，资源调度最直接。
宿主操作系统（Host OS）：在虚拟化场景中，先安装在物理机上的操作系统，负责管理硬件并承载 Hypervisor 或虚拟化组件。
客户操作系统（Guest OS）：运行在虚拟机或容器中的操作系统实例，它“以为”自己独占硬件，实际上资源由上层虚拟化层分配。

多OS 的本质，就是同一台物理机上同时存在多个操作系统实例。它们可能是多个 Guest OS，也可能是 Host OS 与若干 Guest OS 并存。理解这一点，才能理解为什么 CPU 核数、内存容量、设备直通会成为规划的核心变量。

二、虚拟化与容器化：隔离层次不同

虚拟化与容器化都能实现“多OS/多环境共存”，但隔离的层次完全不同。

虚拟化通过 Hypervisor 模拟完整硬件，每个虚拟机拥有独立的内核、驱动和系统调用接口。Guest OS 与 Host OS 之间是硬件级隔离，一个 Guest 崩溃通常不会直接影响另一个 Guest。

容器化则共享 Host OS 内核，通过 namespace 做视图隔离、cgroup 做资源限制。容器里通常不安装完整 Guest OS，只打包应用与依赖。它启动快、开销小，但隔离强度弱于虚拟机，且内核版本由 Host 决定。

  一句话区分：虚拟机虚拟的是“硬件”，容器虚拟的是“操作系统视图”。前者每个实例带内核，后者共享内核。

三、Hypervisor：多OS 的资源仲裁者

Hypervisor（虚拟机监视器）是虚拟化的核心组件，负责 CPU 时间片分配、内存映射、设备模拟与中断注入。按部署方式分为两类：

Type 1（裸金属型）：直接运行在硬件上，如 VMware ESXi、Microsoft Hyper-V、KVM（内核态集成）。性能高、延迟低，常用于生产服务器。
Type 2（宿主型）：运行在 Host OS 之上，如 VirtualBox、VMware Workstation。便于桌面使用，但多一层调度开销。

Hypervisor 决定了 Guest OS 能看到多少 vCPU、多少内存、哪些设备。因此，多OS 资源规划的第一手参数，往往来自 Hypervisor 的配置，而不是 Guest 内部看到的数字。

四、Guest OS 与 Host OS 的关系

Host OS 与 Guest OS 之间是“宿主—租客”关系，但资源路径并非简单叠加。以 KVM 为例，Guest 的 vCPU 实际是 Host 上的一个线程，由 Host 调度器分配物理核；Guest 内存由 Host 通过 EPT/影子页表映射；设备 I/O 可能经过 Host 内核、用户态模拟或直通。

这意味着：Guest 内看到的 CPU 使用率、内存空闲量，并不等于物理机真实余量。规划时必须同时观察 Host 层与 Guest 层，否则容易出现“每个 Guest 都不忙，但物理机已过载”的假象。

五、案例：一台 64 核物理机的多OS 规划

假设一台物理机为 64 物理核、512 GB 内存，计划运行 4 台业务虚拟机与若干容器。若简单按“每台 Guest 16 vCPU、128 GB”分配，看似刚好，但实际会出问题：Host OS 自身需要约 4～8 核处理中断与调度，Hypervisor 需要内存做页表与缓存，容器还要共享剩余资源。

物理机：64 cores / 512 GB
Host OS 预留：8 cores / 32 GB
Hypervisor 开销：约 2% 内存 ≈ 10 GB
可用给 Guest + 容器：56 cores / 470 GB

若 4 台 Guest 各配 12 vCPU / 96 GB：
  Guest 合计：48 vCPU / 384 GB
  剩余给容器：8 cores / 86 GB
  结论：vCPU 可轻度超卖，内存不宜超卖

这个例子说明：多OS 规划不是把物理资源平均分，而是先扣除 Host 与 Hypervisor 的固定开销，再按业务优先级分配。

六、常见误区与复盘

误区	问题	正确做法
把容器当轻量虚拟机	忽略共享内核带来的隔离与内核版本约束	明确容器共享 Host 内核，安全与升级需整体考虑
Guest 内存按物理内存等分	忽略 Host 与 Hypervisor 开销，导致 Host OOM	先预留 Host 内存，再分配 Guest，并设置内存超卖上限
vCPU 与物理核 1:1 绑定	资源利用率低，无法应对突发负载	按业务类型适度超卖，关键业务可做 CPU 亲和绑定
只看 Guest 内部监控	看不到 Host 层争抢与 steal time	同时采集 Host 与 Guest 指标，关注 CPU steal、内存回收

复盘要点：多OS 资源规划的核心不是“分得多细”，而是“先算清 Host 与 Hypervisor 的固定成本，再决定 Guest 与容器的可分配上限”。任何忽略宿主层开销的分配方案，都会在负载上升时暴露问题。

掌握操作系统类型、虚拟化与容器化的层次差异、Hypervisor 的仲裁角色，以及 Guest OS 与 Host OS 的资源传递关系，是后续进行 CPU 超卖、内存预留、设备直通与容器限额计算的前提。只有把层次关系看清楚，容量规划才不会停留在“数字平均分”的层面。