📚 课程目录第3章 KVM架构原理

3. KVM架构原理

KVM 虚拟化并不是一个单独运行的软件，而是由内核态、用户态和管理态三层组件协同构成的完整体系。理解这三者的职责边界与协作路径，是掌握 KVM 设备虚拟化与系统集成的第一步。很多初学者误以为“装了 KVM 就能跑虚拟机”，实际上 KVM 只提供 CPU 与内存的硬件虚拟化能力，设备模拟、镜像管理、生命周期控制分别由 QEMU 和 libvirt 承担。

一、三层架构的核心职责

KVM 体系可以拆解为三个层次，每层解决不同的问题：

KVM 内核模块：以 kvm.ko、kvm_intel.ko 或 kvm_amd.ko 形式加载进 Linux 内核，把宿主机内核变成一个 Hypervisor。它负责 vCPU 的创建与调度、内存的二级地址转换（EPT/NPT）、VM-Exit/VM-Entry 处理，以及中断控制器的虚拟化支持。
QEMU 用户态模拟：作为运行在用户空间的进程，QEMU 负责模拟主板、磁盘、网卡、USB、显卡等设备，并管理虚拟机的内存映射与 I/O 请求。它通过 /dev/kvm 字符设备调用 KVM 提供的 ioctl 接口，把 CPU 执行交给硬件虚拟化。
libvirt 管理接口：以 libvirtd 守护进程为核心，向上提供统一的 XML 描述与 API，向下调用 QEMU。它负责虚拟机的定义、启动、停止、迁移、存储池与网络管理，是云平台和自动化工具对接 KVM 的标准入口。

一句话概括：KVM 管“算”，QEMU 管“设备”，libvirt 管“编排”。三者缺一不可，但职责绝不重叠。

二、三者协作机制：从一条 virsh 命令说起

下面这张图展示了从管理命令到硬件虚拟化的完整信号链与数据流路径。它把 libvirt、QEMU、KVM 内核模块以及硬件之间的调用关系、控制流和 I/O 路径放在同一张图中，便于对照理解。

当执行 virsh start web-vm 时，实际发生的调用链如下：

libvirt 读取 /etc/libvirt/qemu/web-vm.xml，解析 CPU、内存、磁盘、网卡等配置。
libvirtd 以合适的参数启动一个 QEMU 进程，并把 XML 中的设备定义转换为 QEMU 命令行。
QEMU 打开 /dev/kvm，通过 KVM_CREATE_VM 创建虚拟机对象，再通过 KVM_CREATE_VCPU 创建 vCPU。
QEMU 为每个 vCPU 启动一个线程，循环执行 ioctl(KVM_RUN)，让 CPU 进入客户机模式。
当客户机执行敏感指令或访问虚拟设备时，触发 VM-Exit，控制权回到 KVM，再由 KVM 返回 QEMU 处理 I/O。
libvirt 通过 QEMU Monitor 和 QMP 协议监控虚拟机状态，并把结果反馈给上层管理平台。

三、关键接口与参数对照

三层之间通过明确的接口通信，下表列出了最核心的交互点与常见参数，便于在排障时快速定位问题所在层。

层次	核心组件	对外接口	典型参数/文件	故障表现
管理态	libvirtd	libvirt API / virsh	domain XML、storage pool	virsh 报 “failed to connect”
用户态	QEMU	QMP / Monitor	-machine、-device、-drive	QEMU 进程退出、设备不识别
内核态	KVM 模块	/dev/kvm ioctl	KVM_RUN、KVM_SET_USER_MEMORY_REGION	dmesg 报 “kvm: disabled by bios”
硬件	CPU 虚拟化扩展	VT-x / AMD-V	VMCS、EPT、IOMMU	嵌套虚拟化性能骤降

四、实操案例：验证三层是否就绪

在部署 KVM 环境时，可以按“硬件 → 内核 → 用户态 → 管理态”的顺序逐层验证。以下命令可直接在宿主机执行：

# 1. 检查 CPU 是否支持硬件虚拟化
grep -E "vmx|svm" /proc/cpuinfo

# 2. 检查 KVM 模块是否加载
lsmod | grep kvm
# 期望输出：kvm_intel 和 kvm

# 3. 检查 /dev/kvm 是否存在且权限正确
ls -l /dev/kvm
# 期望：crw-rw---- 1 root kvm

# 4. 检查 QEMU 是否可用
qemu-system-x86_64 --version

# 5. 检查 libvirt 服务状态
systemctl status libvirtd
virsh list --all

如果第 2 步没有输出，说明 KVM 模块未加载，可尝试 modprobe kvm_intel；如果第 3 步提示权限不足，需要把当前用户加入 kvm 组并重新登录。

五、常见误区与复盘

误区一：把 QEMU 当成 KVM。 QEMU 可以独立运行纯软件模拟，速度极慢；只有配合 KVM 才能获得接近原生的性能。判断依据是 QEMU 命令行中是否出现 -enable-kvm 或 -accel kvm。
误区二：认为 libvirt 是必须的。 直接使用 QEMU 命令行也能启动虚拟机，但缺乏统一的生命周期管理和资源编排，不适合生产环境。libvirt 的价值在于标准化和可编程。
误区三：忽略内核模块版本匹配。 KVM 模块与内核版本强绑定，升级内核后需要重新加载对应模块，否则可能出现 /dev/kvm 缺失或 ioctl 失败。
误区四：在虚拟机中直接嵌套 KVM 却不开启 nested。 需要在宿主机加载模块时设置 kvm_intel nested=1，否则客户机内无法再创建 KVM 虚拟机。

排障时建议遵循“自下而上”的顺序：先确认 CPU 虚拟化已开启，再确认 KVM 模块与 /dev/kvm 正常，然后验证 QEMU 能否独立启动，最后检查 libvirt 的 XML 与日志 /var/log/libvirt/qemu/<vm>.log。这样能避免在错误层次上反复折腾。

掌握 KVM、QEMU、libvirt 三者的分工与协作，就相当于拿到了 KVM 虚拟化体系的“地图”。后续无论是配置 virtio 设备、做 PCI 直通，还是对接 OpenStack，都可以回到这张地图上定位问题属于哪一层、由哪个组件负责。