---
url: /courses/virtualization-tech/01-virtualization-kvm-readiness/index.md
---
# 第 1 课 一台主机为什么能装下多台电脑

::: tip 项目目标
你将以“星舟实训云”初级运维工程师的身份，为一台 Ubuntu 主机完成虚拟化上线前检查：说清虚拟化解决什么问题，画出 KVM、QEMU 与 libvirt 的协作关系，检查处理器、内存、存储和软件条件，安装 KVM/libvirt 管理栈，并用可复核证据证明这台主机已经具备创建虚拟机的基础条件。

这台主机上要跑的课程实验彼此独立，如果每套环境各占一台物理机，机器大部分时间闲置，恢复和布线成本也高。教材与后续章节的来宾创建、网络和存储管理都建立在 KVM/libvirt 主线上：KVM 随 Linux 内核提供硬件加速，性能接近物理机；libvirt 统一管理虚拟机生命周期、网络与存储。所以本课先把 KVM 环境搭好，后续课程都在这条主线上推进。
:::

![学生在 Ubuntu 主机旁检查 KVM 实训平台，屏幕只呈现抽象虚拟机卡片，不含命令和精确拓扑](./assets/01/virtualization-lab-illustration.png)

先花两分钟确认你的起点。下面的自测结果会帮课程助教判断该从哪里开始讲。

{{assessment:lesson-01-precheck}}

## 1.1 为什么需要虚拟化

::: warning 先看问题，再谈技术
先想清楚：学校如果为每个小实验都准备一台独立物理电脑，会发生什么？
:::

假设你要同时学习 Linux 服务器、Windows 桌面和 Ubuntu 桌面。如果每个系统都占一台独立物理机，会出现三个问题：

* **大部分时间闲置**：上课只有几个小时，但机器 24 小时开机，CPU 和内存利用率很低。
* **系统坏了恢复慢**：每台机器都要重新装系统、装软件，一次故障可能要折腾半天。
* **布线和维护成本高**：机器越多，电费、网口、空间和管理工作量越大。

虚拟化尝试解决这个问题：**把一台物理主机的处理器、内存、存储和网络，组织成多套彼此隔离的“数字电脑”**。这样一台机器就能同时跑好几个系统，资源利用率更高，环境也更容易重建。

### 虚拟化技术从哪里来

这个思路的源头要回到几十年前的大型机时代。那时候一台大型机非常昂贵，一个机构能拥有一台就算相当豪华。这么贵的机器只给一个人用，浪费巨大，于是出现了**分时系统**：许多人用各自的终端连接同一台大型机，按时间片轮流使用它的算力。这是最早“一台机器服务很多人”的形态。

后来 x86 服务器普及，价格一路走低，每个部门、每项业务都愿意买一台自己的服务器。新问题跟着来了：服务器多了，闲置也多。一台服务器往往只跑一个业务，剩下的大部分算力在空转，CPU 利用率常常只有个位数。

虚拟化把这两条思路合在一起：既保留“一台机器服务多份工作”，又让拆分工作由软件自动完成。一台物理机被拆成多台彼此隔离的“数字电脑”，每份工作各用各的，物理资源却共享同一份。**一台当多台**，闲置的算力被重新利用，一台机器顶原来好几台用。这个能力最终成为云计算的底座。

### 虚拟化的收益

| 收益 | 具体表现 |
| --- | --- |
| 提高资源利用率 | 一台宿主机同时跑多个来宾，把闲置的 CPU 和内存用起来 |
| 降低硬件与电力成本 | 用更少的物理机完成同样多的工作，少买机器、少耗电、少占空间 |
| 环境隔离 | 一台虚拟机崩溃，通常不影响同一宿主机上的其他虚拟机 |
| 快速克隆测试环境 | 复制一份虚拟机就能得到一套全新环境，做坏了随时重来 |
| 灾备与迁移方便 | 整个来宾就是宿主机上的普通文件，可以打包备份、拷到别的机器继续跑 |

### 虚拟化的代价

收益要付出代价才能拿到，虚拟化也一样：

* **性能开销**：CPU、内存、磁盘都要经过虚拟化层转发，多少会有损耗，跑密集计算任务时感受明显。
* **管理复杂度**：一台物理机变成了“多台”逻辑机器，补丁、备份、网络规划都要多管一份。
* **需要专门技能**：分配内存、规划 vCPU、排查隔离问题，都需要额外学习。

### 什么场景适合用虚拟化

| 场景 | 适合度 | 原因 |
| --- | --- | --- |
| 多系统并存 | 非常适合 | 一台宿主机同时跑 Windows 和 Linux，省掉多台硬件 |
| 测试环境 | 非常适合 | 克隆、快照、随时重建，做实验的成本很低 |
| 服务器整合 | 非常适合 | 把多个低负载业务合并到少数几台物理机上 |
| 对性能极度敏感的单体应用 | 不太适合 | 虚拟化层的开销会拖慢需要全部算力的任务 |
| 资源已饱和的机器 | 不太适合 | 宿主机自己都快不够用了，再分给来宾只会更紧张 |

### 虚拟化与云计算的关系

你可能见过云服务商提供的 IaaS、PaaS、SaaS：IaaS 给你一台台“虚拟出来的服务器”自己折腾，PaaS 直接给你运行环境，SaaS 连安装都省了，打开网页就能用。无论哪一层，底下都站着虚拟化。云计算把虚拟化的能力包装成“随时按需购买”的服务，而虚拟化是把一台物理机拆成多台“数字电脑”的那块基石。本课程学的就是这块基石本身：先弄清楚一台机器怎么装下多台电脑。

::: tip 关键结论
虚拟化把一台物理主机的资源**更灵活地分配和复用**。物理内存总量固定，虚拟机的内存都从这块总量里划分，所以分配时要给宿主机自身留出余量。
:::

### 常见误区对照

| 常见说法 | 正确判断 |
| --- | --- |
| “一台电脑能开很多虚拟机，所以资源变多了” | 资源没有变多，只是被更灵活地分配和复用 |
| “虚拟机互相隔离，所以绝对安全” | 隔离能缩小影响范围，但仍需要更新、权限和网络安全措施 |
| “装了 KVM 就一定很快” | 还取决于来宾配置、内存、存储、驱动、负载和资源竞争 |

## 1.2 核心概念：宿主机、虚拟机、来宾系统与 Hypervisor

::: tip 公寓类比
把一台物理主机想象成一栋公寓：

* **宿主机（Host）** 是整栋楼，提供真实的处理器、内存、磁盘和网卡。
* **虚拟机（VM）** 是划分出来的房间，每间房看到自己的“电脑”。
* **来宾系统（Guest OS）** 是住进房间的人，本课程会有 Ubuntu Server、Ubuntu Desktop 和 Windows 三类来宾。
* **Hypervisor** 像物业与楼宇控制系统，负责安排谁在什么时候使用真实资源，并保持不同房间的边界。
* **虚拟硬件** 像房间里的水表、电表和门锁。来宾看到的是虚拟 CPU、虚拟磁盘和虚拟网卡，不直接控制整栋楼。
  :::

```mermaid
flowchart TB
  H["Ubuntu 宿主机：真实 CPU / 内存 / SSD / 网络"]
  V["虚拟化层：KVM + QEMU + libvirt"]
  A["来宾 A：Ubuntu Server"]
  B["来宾 B：Ubuntu Desktop"]
  C["来宾 C：Windows"]
  H --> V
  V --> A
  V --> B
  V --> C
```

### Hypervisor 的两种类型

Hypervisor 按安装位置分成两类：

| 对比维度 | Type 1 裸机型 | Type 2 宿主型 |
| --- | --- | --- |
| 装在哪里 | 直接装在物理硬件上 | 装在操作系统之上 |
| 代表产品 | KVM、VMware ESXi | VMware Workstation、QEMU |
| 性能 | 高，接近物理机 | 略低，中间隔了一层操作系统 |
| 使用场景 | 企业数据中心、服务器整合 | 桌面学习、个人实验 |
| 上手难度 | 需要专业运维经验 | 装上即用，界面直观 |

::: tip 本课程用哪类
KVM 属于 **Type 1 裸机型**，但它不是一款独立安装的软件：KVM 是**Linux 内核模块**，装上后 Ubuntu 内核本身就具备了硬件加速虚拟化能力，在**内核态**直接调度，性能接近物理机。**libvirt** 则是**用户态管理面**：它统一管理 QEMU/KVM 的虚拟机生命周期、网络与存储，`virsh`、`virt-manager` 都通过它工作。本课程使用 **KVM + libvirt** 组合：内核提供加速能力，libvirt 提供统一管理。
:::

### 虚拟化技术谱系：四种常见路线

| 技术路线 | 原理 | 特点 | 常见代表 |
| --- | --- | --- | --- |
| 全虚拟化 | 由虚拟化层模拟完整硬件，来宾无需任何修改 | 兼容性好，任意系统都能装 | 早期的 QEMU |
| 半虚拟化 | 来宾通过专门接口与宿主机协作 | 性能好，但要先修改来宾系统 | Xen 的某些模式 |
| 硬件辅助虚拟化 | CPU 提供 VT-x / AMD-V 指令，隔离与切换由硬件直接完成 | 现代主流，性能接近原生 | 现代 QEMU/KVM、Hyper-V |
| 软件模拟 / 仿真 | 逐条解释指令，模拟目标硬件 | 兼容性最强，速度最慢 | 跨平台模拟器 |

::: tip KVM 属于哪一类
KVM 采用**硬件辅助虚拟化**作为主路线：当 CPU 具备 VT-x 或 AMD-V 扩展时，来宾的关键指令直接在真实处理器上执行，速度接近原生。QEMU 也可以在 KVM 之外做纯软件模拟，逐条解释指令，性能明显下降。全虚拟化与半虚拟化的区别在这条主线下较少出现，你记住“KVM 以硬件辅助为主、QEMU 纯模拟兜底”这个判断即可。
:::

::: warning 为什么 CPU 虚拟化扩展重要
如果 CPU 不支持或未开启虚拟化扩展，KVM 无法提供硬件加速，只能退回 QEMU 纯软件模拟，性能会很差。这就是本课第一步要检查 CPU 虚拟化能力的原因。
:::

## 1.3 Docker 与虚拟化：别把两类“房间”弄混

上学期学习 Docker 时，我们用公寓类比过容器：每个容器像一间隔间，共享大楼的公共设施。虚拟机的公寓类比看起来差不多，但两者隔离的层次完全不同。

| 对比维度 | 虚拟机（KVM） | 容器（Docker） |
| --- | --- | --- |
| 隔离什么 | 一整台“电脑”：独立的完整操作系统，自带内核 | 应用运行环境：共享宿主机内核，只隔离进程 |
| 内核 | 每个来宾系统都有自己的内核 | 所有容器共用宿主机的内核 |
| 启动速度 | 要启动完整操作系统，通常以分钟计 | 只启动应用进程，通常以秒计 |
| 资源占用 | 每台虚拟机占用完整系统资源（内存、磁盘较大） | 多个容器共享宿主系统资源，占用小 |
| 隔离强度 | 强：来宾系统崩溃通常不影响宿主机 | 弱：容器共享内核，边界靠内核特性隔离 |
| 典型场景 | 运行不同操作系统、需要完整系统环境 | 打包和运行单个应用、微服务 |

::: tip 一句话记忆
虚拟机隔离“整台电脑”，容器隔离“应用环境”。Docker 容器共享宿主机内核，所以容器里不能运行一个和宿主机不同内核的系统（例如在 Linux 宿主上直接跑 Windows 内核）；虚拟机自带内核，可以在任何宿主上运行不同系统。
:::

::: warning 两者的关系
虚拟机和容器是同一类“资源复用”思路下的两种不同技术，适合的场景不同。本课程主线是虚拟机；Docker 容器在后续课程中会单独使用，两者都需要掌握，但不能混为一谈。
:::

## 1.4 KVM/QEMU/libvirt 管理栈

你可能会把 KVM、QEMU、libvirt、virt-manager 都叫做“虚拟机软件”。它们确实一起工作，但分工完全不同。四个角色合在一起，才构成一套完整的虚拟机管理栈：

| 组件 | 所在位置 | 一句话职责 | 本课验收方式 |
| --- | --- | --- | --- |
| KVM | Linux 内核模块 | 提供处理器和内存虚拟化能力，让内核具备运行硬件加速虚拟机的基础 | `kvm-ok`、`/dev/kvm` |
| QEMU | 用户空间进程 | 创建一台虚拟电脑的设备模型并运行来宾；与 KVM 配合时获得硬件加速 | `qemu-system-x86_64 --version` |
| libvirt | 系统服务与管理 API | 统一管理虚拟机生命周期、配置、网络和存储，屏蔽底层差异 | `virsh -c qemu:///system uri` |
| virt-manager | 图形管理工具 | 通过 libvirt 以图形界面创建和查看虚拟机 | `virt-manager --version` |

::: tip 图形界面适合学习
virt-manager 把创建、配置、启动虚拟机都做成了可视化的向导和窗口，每一步都有提示。本课程统一使用它管理虚拟机，先把流程和概念掌握清楚。
:::

### 一次“启动虚拟机”请求的完整旅程

下面用动画演示：你在 virt-manager 点击“启动”后，请求如何一层层传到物理硬件。先观察每一层做了什么，再对照下面的文字解释。

```mermaid
flowchart LR
  U["学生操作"] --> GUI["virt-manager：图形客户端"]
  U --> CLI["virsh：命令行工具"]
  GUI --> L["libvirt：统一管理 API 与服务"]
  CLI --> L
  L --> Q["QEMU：来宾进程与虚拟设备"]
  Q --> K["KVM：Linux 内核加速"]
  K --> CPU["物理处理器的虚拟化能力"]
```

这个动画模拟了五层协作：**学生操作 → virt-manager → libvirt → QEMU → KVM → 物理硬件**。观察要点：

1. virt-manager 是管理入口，你在界面上做的每个操作，都会转换成对 libvirt 的请求。
2. 每台虚拟机有一份 libvirt 定义文件，记录它“想要多少 CPU、内存和磁盘”。
3. 真正执行指令的是物理硬件，虚拟机只是获得了一部分真实资源的“使用权”。

::: details 补充：虚拟机在磁盘上长什么样
每台 KVM 虚拟机至少包含两类文件：

* **libvirt 定义文件（XML）**：记录虚拟机的硬件参数（CPU、内存、磁盘、网卡）。
* **`.qcow2` 虚拟磁盘文件**：保存虚拟机的硬盘内容，包括操作系统和所有数据。

这两个文件都在宿主机的普通文件系统里。删除虚拟机时，通常同时删除这两类文件才能彻底释放空间。
:::

## 1.5 CPU 与内存是怎么被虚拟化的

::: tip 本节学什么
前面说了 KVM/QEMU 会“分配真实资源”，具体是怎么分配的？本节讲清 CPU 和内存的虚拟化基础。理解了这两个核心，创建虚拟机时设置的 vCPU 数量和内存大小到底代表什么，你就有依据了。
:::

### CPU 虚拟化：一个物理核分成多个 vCPU

物理电脑的 CPU 里有若干个核（core），每个核同时只能执行一条指令流。虚拟化的目标，是让一台虚拟机觉得自己“拥有一整颗 CPU”。要做到这一点，先要面对 CPU 上的一道天然分界：特权级。

#### 难点：内核态与用户态

CPU 执行指令分成两类权限：

| 权限级别 | 谁在使用 | 能做什么 |
| --- | --- | --- |
| 高特权（内核态） | 操作系统内核 | 直接访问硬件、管理内存、响应中断 |
| 低特权（用户态） | 普通应用程序 | 只做日常计算，想碰硬件要请内核代办 |

来宾系统也有自己的内核，它同样要执行这些“内核级”指令。让一个“宾客内核”安全地运行高特权指令，又不能让它真的控制宿主机的硬件，这是虚拟化最难的地方之一。

#### 硬件辅助虚拟化：CPU 腾出一个“客人模式”

现代 CPU 内置了虚拟化扩展（Intel 的 VT-x、AMD 的 AMD-V）。CPU 增加了一个专供虚拟机使用的受限运行模式：来宾内核在这个模式下也能安全执行关键指令，隔离和切换由硬件直接完成，速度接近原生。如果 CPU 不支持或未开启虚拟化扩展，QEMU 只能退回软件模拟，靠程序逐条解释指令，性能会明显下降。

#### vCPU 与真实物理核

创建虚拟机时选择“2 个 vCPU”，这两个核是虚拟出来的。宿主机有多少物理核是固定的，QEMU/KVM 用时间片轮转，让一个物理核在极短的时间窗口里轮流喂多台虚拟机，每台虚拟机都觉得自己在独占运行。多核 CPU 提供了更多可分配的物理核，超线程则让每个物理核同时处理两路任务，可调度的位置更多了。

```mermaid
flowchart LR
  C["宿主机物理核（实体）"]
  C --> A1["时间片 1：喂虚拟机 A 的 vCPU"]
  C --> A2["时间片 2：喂虚拟机 B 的 vCPU"]
  C --> A3["时间片 3：喂虚拟机 A 的另一个 vCPU"]
```

::: tip 观察点：看起来很多核，不一定真有那么多核
在虚拟机里打开任务管理器，看到 4 个核、8 个核，这只能说明虚拟机“以为”自己有那么多核。vCPU 是调度出来的时间份额，真正的计算仍由宿主机的物理核完成。vCPU 设置得再多，算力也不会凭空增加，多台虚拟机还会在同一个物理核上互相排队。
:::

::: tip 为什么本课要检查 vmx / svm
`/proc/cpuinfo` 里的 `vmx`（Intel）或 `svm`（AMD）标志，表示 CPU 的硬件虚拟化扩展对操作系统可见。看到它，说明硬件加速可用，虚拟机性能才有保障。这也是你在安装前要检查它的原因。
:::

### 内存虚拟化：从宿主物理内存里划一块给虚拟机

物理内存总量固定，是稀缺资源。内存虚拟化解决一个核心矛盾：来宾系统“以为”自己拥有一整块属于它的内存，但这些内存的实际位置都在宿主机上。

#### 地址转换：把“虚拟机以为的地址”翻译成真实地址

虚拟机访问自己那块内存时，CPU 要把“虚拟机以为的地址”翻译成“宿主机真实的物理地址”。早期这个翻译靠软件逐条完成，速度慢；现代 CPU 的 EPT（Intel）/ NPT（AMD）硬件特性直接在芯片里完成翻译，速度接近原生。

```mermaid
flowchart LR
  G["虚拟机以为的内存地址"] --> T["地址翻译 EPT / NPT（硬件加速）"]
  T --> H["宿主机真实的物理内存地址"]
```

#### 内存超卖：多台虚拟机同时要内存

宿主机内存有限，多台虚拟机同时要内存时，QEMU/KVM 负责分配和回收，每台虚拟机按你设置的大小拿到一份“额度”。当所有虚拟机的额度加起来超过宿主物理内存总量，就出现了内存超卖：它能把内存用得更满，但超额太多会导致系统变慢甚至不稳定。

::: tip 创建时为什么要给宿主留余量
QEMU/KVM 自身、宿主机的桌面和系统服务都要消耗内存。把内存设置得很满，宿主自己就没内存可用了。稳妥的做法是先看宿主机总内存，给宿主留出余量，再分配来宾的内存。

一句话记忆：虚拟机的内存来自宿主机那块总量固定的物理内存，开再多虚拟机，总量也不会变多。
:::

::: details 深入阅读预告
时间片如何公平分配、内存分页与交换，这些调度细节会在后面的“虚拟化原理”专章展开。本小节先建立基本认识。
:::

## 1.6 虚拟设备：I/O 虚拟化与增强功能

::: tip 本节学什么
CPU 和内存解决的是“算”的问题，虚拟设备解决的是“用”的问题：虚拟机怎么上网、怎么存取文件、怎么显示画面？本节认识 QEMU/KVM 的虚拟网卡、虚拟磁盘、虚拟显卡，以及配套的加速与体验增强组件。
:::

### 设备模拟：用软件造出一台“假硬件”

QEMU 用软件模拟出网卡、磁盘控制器、显卡等设备。来宾系统里的驱动程序像驱动真实硬件一样驱动它们，不需要知道自己面对的是软件。这个做法的好处是兼容：无论宿主机换成什么真实硬件，来宾看到的设备始终是同一套。

```mermaid
flowchart TB
  G["来宾系统里的应用程序"]
  D["虚拟网卡 / 虚拟磁盘 / 虚拟显卡"]
  V["QEMU 虚拟设备层"]
  H["宿主机真实网卡 / 磁盘"]
  G --> D --> V --> H
```

### 半虚拟化：给来宾一条更快的通道

纯软件模拟的每一笔读写都要经过一层翻译，速度慢。QEMU/KVM 提供优化过的设备接口（半虚拟化设备，例如 VirtIO 网卡和磁盘），配合来宾系统里安装的对应驱动，双方约定一套高效的数据交换方式，网络和磁盘读写明显更快。这些接口的底层原理留到后面的虚拟化原理章节，你只需要记住：给虚拟机装上配套驱动，I/O 速度会更快。

### 增强功能：来宾代理与 SPICE 显示

桌面虚拟化软件通常会给来宾装一组“体验升级包”。KVM 体系里对应的组件是 \*\*QEMU 来宾代理（Guest Agent）\*\*和 **SPICE 显示协议**，装好之后立刻能感受到的变化：

| 功能 | 效果 |
| --- | --- |
| 剪贴板共享 | 通过 SPICE 通道，虚拟机里复制的文字能直接粘贴到宿主机 |
| 自适应分辨率 | 拖动 virt-manager 窗口大小，桌面分辨率自动跟随 |
| 优雅关机 | 宿主机通过 libvirt 请来宾正常关闭系统，而不是直接断电 |
| 快照前冻结文件系统 | 来宾代理让磁盘进入一致状态，再生成快照 |

::: tip 本课程后续会用到
后续创建来宾系统时，会安装 QEMU Guest Agent 并验证这些功能。它能明显改善实验体验，也是排错时判断来宾“是否活着”的线索之一。
:::

### 虚拟网络：四种模式怎么选

KVM 主机安装 libvirt 后会自动创建一个名为 `default` 的虚拟网络（对应虚拟网桥 `virbr0`）。每台虚拟机的虚拟网卡连到哪种网络，由网络模式决定：

| 模式 | 通俗理解 | 本课程用途 |
| --- | --- | --- |
| NAT（libvirt 默认网络） | 虚拟机藏在宿主机后面上网，外部网络看不到它 | 默认 `default` 网络，本课程主要使用 |
| 桥接 | 虚拟机像一台独立电脑，直接连上物理网络 | 需要对外提供服务时使用 |
| 仅主机 | 只能与宿主机通信，不能上外网 | 做隔离环境实验 |
| 隔离网络 | 只有同一虚拟网络中的虚拟机之间能通信 | 做多机联调实验 |

::: tip 为什么本课默认用 NAT
libvirt 的 `default` 网络就是一个 NAT 网络，虚拟机接入后可以正常访问外网，能下载软件、更新系统，同时不需要占用额外的网络地址，最省事。桥接、仅主机和隔离网络各有用途，网络章节会逐个展开讲解。
:::

## 1.7 虚拟磁盘：账面大小与实际占用

::: tip 为什么现在讲磁盘
你第一次创建虚拟机时，会面对磁盘格式和分配方式的选项。不理解它们的区别，你就不知道为什么磁盘“看起来 100GB，实际只占几 GB”。
:::

观察要点：

1. **动态分配**：`.qcow2` 文件先小后大，虚拟机写入多少数据，文件才增长多少。节省宿主机空间，是本课默认选择。
2. **固定大小**：创建时立即占满整块空间，性能更稳定，但宿主机剩余空间会立刻减少。
3. 无论哪种，虚拟机看到的“磁盘容量”都是你设置的上限，不会因为动态分配而缩水。

::: tip 本课结论
本课程默认使用**动态分配的 qcow2 磁盘**：既满足实验需求，又不浪费宿主机空间。固定大小更适合追求稳定性能的生产场景，后续存储课会深入讲解。
:::

## 1.8 安装前检查：先检查，再改变系统

在安装任何软件之前，先建立环境基线。按顺序完成以下检查。

:::: steps

1. **记录 Ubuntu、内核和资源**

   这些命令输出 Ubuntu 版本、内核、CPU、内存和磁盘余量，是后续判断的基准。

   ```bash
   date -Is
   lsb_release -ds
   uname -r
   uname -m
   lscpu | grep -E 'Model name|Architecture|CPU\(s\)|Core|Thread|Virtualization'
   free -h
   df -h /
   ```

2. **检查 CPU 虚拟化能力**

   Ubuntu 上可用以下命令检查 CPU 是否向操作系统暴露虚拟化扩展：

   ```bash
   grep -m1 -E '^flags.*\b(svm|vmx)\b' /proc/cpuinfo
   ```

   ::: tip 预期结果
   Intel 处理器预期看到 `vmx`，AMD 处理器预期看到 `svm`，表示硬件虚拟化扩展对系统可见。
   :::

3. **检查 KVM 模块与设备入口**

   确认 KVM 内核模块是否加载、设备文件是否存在：

   ```bash
   lsmod | grep -E '^kvm(_intel)?\b'
   ls -l /dev/kvm
   ```

   ::: tip 预期结果
   预期看到 `kvm`、`kvm_intel` 相关模块，以及 `/dev/kvm` 设备文件。如果看不到，先记录现象，不要自行修改固件；由教师确认这台机器是否运行在另一层虚拟环境中。
   :::

4. **安装检查工具 cpu-checker**

   `cpu-checker` 提供 `kvm-ok` 检查命令，四层验收时会用到，先把它装好：

   ```bash
   sudo apt update
   sudo apt install -y cpu-checker
   ```

   ::: tip 预期结果
   安装完成后，`command -v kvm-ok` 能输出命令路径，说明检查工具已就绪。
   :::

::::

把关键输出截图保存，并填进下面的检查表：

| 项目 | 你的结果 | 判断 |
| --- | --- | --- |
| Ubuntu 版本 |  | 记录实际版本，不凭印象 |
| 内核版本 |  | 后续排错必须带上 |
| 处理器型号 |  | 应与实验室设备标签交叉核对 |
| 架构 |  | 本课程预期 `x86_64` |
| 可用内存 |  | 为宿主保留余量，不把全部分给来宾 |
| 虚拟化标志 |  | Intel 为 `vmx`，AMD 为 `svm` |
| KVM 模块状态 |  | `lsmod` 中能看到 `kvm`、`kvm_intel` |
| `/dev/kvm` 设备 |  | 设备文件存在，权限正常 |
| 根文件系统余量 |  | 下一课创建磁盘前还要再次检查 |

## 1.9 安装 KVM/libvirt 管理栈

Ubuntu 的官方软件源中带有整套 KVM/libvirt 组件，可以直接安装：

```bash
sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients virt-manager virtinst cpu-checker
```

| 软件包 | 本课用途 |
| --- | --- |
| `qemu-kvm` | 安装 Ubuntu 提供的 QEMU/KVM 运行组件 |
| `libvirt-daemon-system` | 提供系统级 libvirt 服务与默认配置 |
| `libvirt-clients` | 提供 `virsh`、`virt-host-validate` 等客户端工具 |
| `virt-manager` | 提供图形管理界面 |
| `virtinst` | 提供 `virt-install` 等创建工具 |
| `cpu-checker` | 提供 `kvm-ok` 检查命令（上一节已装好，这行会跳过它） |

::: tip 版本差异
不同 Ubuntu 版本提供的软件包版本可能不同。安装完成后，用 `virsh --version`、`qemu-system-x86_64 --version` 查看当前版本。
:::

安装完成后，把当前账号加入 `libvirt` 和 `kvm` 管理组：

```bash
sudo adduser "$USER" libvirt
sudo adduser "$USER" kvm
```

::: tip 重新登录后才生效
加入管理组后，必须注销当前桌面会话并重新登录，仅关闭一个终端窗口不一定刷新组成员身份。重新登录后用 `id -nG` 检查，输出应包含 `libvirt` 和 `kvm`。
:::

接下来做一次快速验证：

```bash
kvm-ok
```

::: tip 第一个验收点
`kvm-ok` 显示硬件加速可用，说明 KVM 环境已经就绪。这是本课的第一个验收点，四层完整验收在下一节。
:::

## 1.10 四层验收：不要只看“安装完成”

按顺序完成以下验收。

:::: steps

1. **验收一：硬件能力对操作系统可见**

   ```bash
   kvm-ok
   ```

   期望看到 `KVM acceleration can be used` 一类的成功信息。若提示命令不存在，检查 `cpu-checker` 是否安装；若提示硬件加速不可用，进入 1.11 排错矩阵。

2. **验收二：KVM 模块与设备入口存在**

   ```bash
   lsmod | grep -E '^kvm(_intel)?\b'
   ls -l /dev/kvm
   ```

   预期能看到 `kvm`、`kvm_intel` 模块和 `/dev/kvm`。设备存在只说明内核侧入口已建立，还要在验收四验证管理连接。

3. **验收三：工具版本可查询**

   ```bash
   qemu-system-x86_64 --version
   virsh --version
   virt-manager --version
   ```

   记录实际版本，不要求全班输出完全相同。

4. **验收四：系统级 libvirt 连接可用**

   ```bash
   virsh -c qemu:///system uri
   virsh -c qemu:///system list --all
   sudo virt-host-validate qemu
   ```

   本课还没有创建虚拟机，因此 `list --all` 显示空表是正常现象。验收重点是能连接 `qemu:///system`。`virt-host-validate` 可能包含本课程未启用功能的警告，只核对 QEMU、KVM 硬件加速与 `/dev/kvm` 等基础项。

::::

::: tip 空列表的含义
第一次执行 `virsh list` 或打开 virt-manager，虚拟机列表是空的，这代表当前还没有创建任何虚拟机。后续每创建一台虚拟机，它才会出现在列表里。
:::

### 保存验收证据

把 `kvm-ok`、KVM 模块与 `/dev/kvm`、工具版本、`qemu:///system` 连接这几步的终端输出截图保存。

## 1.11 故障演练：virsh 连不上 qemu:///system

### 故障注入

::: warning 模拟方式
下面的环境变量只对这条命令生效，不会永久修改 libvirt 配置。完成后按排错步骤恢复，不影响系统其他部分。
:::

在终端里故意把连接目标设成一个不存在的 URI：

```bash
LIBVIRT_DEFAULT_URI='qemu:///does-not-exist' virsh list --all
```

预期看到无法连接、找不到套接字或路径之类的错误。不同版本的错误文本可能不同，不按某一句英文逐字判分。

### 诊断思路

1. **现象**：`virsh` 命令存在，但列出虚拟机时报连接错误。
2. **假设**：客户端连接目标错误，不一定是 KVM 硬件坏了。
3. **检查**：显式指定课程统一的系统级 URI，重新执行。
4. **修复**：使用正确连接目标重新执行。
5. **复验**：能返回空表或虚拟机列表，且 URI 为 `qemu:///system`。

```bash
virsh -c qemu:///system uri
virsh -c qemu:///system list --all
```

### 排错矩阵

| 现象 | 先查 | 常见原因 | 处理 |
| --- | --- | --- | --- |
| `kvm-ok: command not found` | 软件包是否安装 | `cpu-checker` 未安装 | 安装该包，再重新检查 |
| `/proc/cpuinfo` 找不到 `vmx`/`svm` | `lscpu`、处理器型号、是否处于另一层虚拟环境 | 固件未开放能力，或上层环境没有暴露 | 保存输出并交教师统一确认，不盲改固件 |
| `/dev/kvm` 不存在 | `lsmod`、`kvm-ok` | KVM 模块未加载或硬件能力不可用 | 记录内核和模块信息，由教师判断 |
| `virsh` 提示权限不足 | `id -nG`、是否重新登录 | 组成员身份未生效 | 确认加入 `libvirt`、`kvm` 组后注销并重新登录 |
| `virsh` 无法连接 | 显式 URI、libvirt 服务状态 | URI 错误、服务未启动、安装未完成 | 使用 `qemu:///system` 并检查 libvirt 服务状态 |
| `virsh list --all` 只有表头 | 命令退出状态与 URI | 本课尚未创建虚拟机 | 这是正常基线，不需要“修复” |
| `virt-host-validate` 有 WARN | 具体检查项名称 | 某些可选能力未配置 | 只按本课验收项判断，保留原始输出 |
| `apt` 提示锁被占用 | 正在运行的软件更新程序 | 后台更新尚未完成 | 等待更新结束；不手工删除锁文件 |

## 1.12 本课提交物

::: tip 提交内容
本课提交以下截图即可：

1. 安装前的环境检查截图（Ubuntu 版本、CPU、内存、磁盘余量、虚拟化标志）；
2. 安装后的四层验收截图（`kvm-ok`、KVM 模块与 `/dev/kvm`、工具版本、`qemu:///system` 连接）；
3. 可选：宿主机、虚拟机、来宾和 KVM/QEMU/libvirt 管理层次的关系概念图。
   :::

::: tip 验收标准

* 环境检查截图包含本机实际信息（Ubuntu 版本、内核、CPU、内存、磁盘余量、虚拟化标志）。
* 验收截图包含 `kvm-ok` 的成功输出、KVM 模块与 `/dev/kvm`、工具版本、`qemu:///system` 连接成功的输出。
* 概念图能说明宿主机、虚拟机、来宾和 KVM/QEMU/libvirt 管理层次的关系。
  :::

## 1.13 本章小测

先独立作答，再核对解析。下面的问题组会直接给出反馈。

{{assessment:lesson-01-check}}

## 本章小结

* 虚拟化把一台宿主机组织成多套隔离的虚拟硬件环境，让物理资源被更充分地复用。
* KVM 是 Linux 内核虚拟化模块，QEMU 负责设备模拟与来宾进程，libvirt 提供统一管理，virt-manager 是图形管理入口。
* 动态分配的 qcow2 虚拟磁盘按需增长，这就是“看起来 100GB、实际只占几 GB”的原理。
* 安装完成后，通过硬件能力、内核模块与设备、工具版本、系统级 libvirt 连接四层验收确认平台可用。
* 错误信息是证据，先确认连接目标和状态，再按提示排查。

下一课将用 virt-manager 创建第一台 Ubuntu Server 来宾 `svr01`。创建前先做资源预算，创建后从虚拟机清单、控制台、来宾系统和服务四层验收。