QEMU 常被介绍为虚拟机工具，用这个说法入门很方便。要理解它为何至今仍在开放基础设施中占据核心位置，还要看它如何划分机器各部分的职责：哪些部分在用户态仿真，哪些交给宿主内核或平台虚拟机监控器（hypervisor）加速。机器状态如何供管理工具读取和控制，存储与设备又有哪些配置需要明确指定，也都由这套设计来安排。[1][2][3][4][5]

这样的分工让 QEMU 有了广泛的用途。开发操作系统时，它可以启动与宿主机架构不同的客户机；运行同架构 Linux 客户机时，可以借助 KVM 加速；由 libvirt 管理虚拟机时，可以负责设备模型。测试集群、嵌入式固件、云镜像、持续集成任务运行器（CI runner）、在线迁移和块设备实验，也都用得上它。这些用途共同依赖一套明确的职责划分，“方便的虚拟机程序”只是使用者最先接触到的一面。[1][6][7]

图片说明：题图是 QEMU 最初的作者 Fabrice Bellard 在 2007 年的真实照片。QEMU 持续发挥作用，源于设计者对机器分工的精确把握：各部分如何协作，都能用程序表达。把客户机笼统地看成一个进程或一台硬件设备，便会遗漏这些细节。[8]

TCG 让跨架构运行成为现实

QEMU 的可移植性依靠 Tiny Code Generator（TCG）。仿真文档说明，TCG 能让 QEMU 在受支持的宿主平台上仿真多种客户机 CPU 架构，并按客户机架构的支持情况，采用系统仿真（system emulation）或用户态仿真（user-mode emulation）。[2] QEMU 因而能够超出宿主 CPU 自身的能力，运行其他架构的软件。

宿主机无法直接执行客户机指令时，TCG 的作用最为突出。x86 工作站可以运行 Arm 固件，开发者可以在难以取得目标硬件时测试 RISC-V 软件镜像，构建系统也能在实体板卡尚未备齐时验证跨架构运行的行为。TCG 的性能是否合适，要看具体工作负载；它首先解决的问题是：能否在这台宿主机上运行所需的客户机系统？

这些工作超出了通常所说的“虚拟化”。跨架构仿真、板级启动调试（bring-up）、指令级分析、固件测试和客户机调试，都需要用软件翻译指令。TCG 承担了这项工作，宿主机即使缺少匹配的虚拟化扩展，QEMU 仍然有用。[2]

KVM 负责加速，QEMU 仍负责设备与配置

宿主机与客户机架构匹配时，QEMU 可以使用加速器（accelerator）。QEMU 的系统仿真入门文档将 KVM、Xen 等加速器与 TCG 并列介绍：默认的 TCG 采用纯仿真方式，硬件虚拟化则需要选择相应的加速器。[1] Linux KVM API 文档说明了用户态程序与内核如何协作：程序打开 /dev/kvm，创建虚拟机（VM）与虚拟 CPU（vCPU）的文件描述符，再用 ioctl 控制虚拟机。[3]

日常所说的“KVM VM”或“QEMU/KVM”，容易让人把两者当成同一个组件。运维时需要分清各自的职责。KVM 提供硬件辅助执行的内核接口；QEMU 仍负责定义机器的内存布局、设备模型、块后端、监控器（monitor）接口和迁移行为，以及客户机能看到的许多硬件细节。

Ubuntu Server 的 QEMU 指南也说明了这层关系：QEMU 是机器仿真器，经常与 KVM 内核组件协作，作为虚拟化工具，让客户机使用硬件虚拟化。[7] 两者的分工由此清楚可见：KVM 加快兼容 CPU 指令的执行，内存、设备和存储等细节仍需要 QEMU 管理。

机器不只是 CPU

QEMU 手册将系统仿真定义为整台机器的虚拟模型，其中包括 CPU、内存和仿真的设备。[1] 操作系统启动时，通常依赖一套完整的板卡或平台约定：总线、存储控制器、网卡、定时器、固件条件、中断控制器和启动顺序，都会影响客户机的运行。

QEMU 的设备仿真文档逐项解释了这些细节。设备前端（front end）呈现给客户机，后端（back end）负责使用宿主资源。设备总线取决于所选的机器模型（machine model），额外设备则用明确的选项指定、查询和挂接。[6] 一条简短的虚拟机启动命令，背后也包含对整台机器的多项选择。

用 QEMU 测试时，开发者可以调整整台机器，测试范围也就超出了单个程序文件。比较不同设备、挂接另一种磁盘后端、测试启动过程，或复现客户机所见的某套硬件配置，都能减少等待实体设备的时间。为此，QEMU 命令行和管理工具需要容纳大量参数；每一项都对应实际的配置需求，有其工程上的理由。

QMP 让管理工具接管客户机

机器运行后，运维人员还需要检查和控制它。QEMU Machine Protocol（QMP）承担这项任务。按协议规范，应用程序可以用这种 JSON 协议操控 QEMU。[4] 相比交互式监控器的命令语法，QMP 更进一步，让启动后的客户机能够纳入统一的管理系统。

借助 QMP，管理工具可以与 QEMU 协商能力、发送命令、接收异步事件。其他程序也能通过 API 访问机器状态，将终端会话中的控制操作纳入自动化管理。[4] QEMU 因而能配合上层管理工具运行，运维人员也能减少对专用命令行的依赖。

这一设计经验同样适用于其他基础设施：控制面需要类型明确、可自动化、可观察的接口。借助 QMP，libvirt 一类管理工具、云编排系统、测试框架和专用虚拟机工具得以调用 QEMU，同时保留对其底层细节的访问。这些细节正是 QEMU 最初的价值所在。[1][4]

存储配置需要逐项说明

虚拟磁盘同样保留了丰富的配置选项。QEMU 磁盘镜像文档列出 raw、qcow2 等受支持的格式，还说明了快照模式（snapshot mode）、虚拟机快照（VM snapshot）、可增长镜像、压缩和 qcow2 的多快照支持等特性。[5] 这些细节需要在设计中认真讨论，因为它们决定性能、可恢复性、可移植性，以及故障发生时的表现。

raw 镜像简单，便于导出给其他仿真器。qcow2 功能更丰富，支持体积较小、可随数据增长的镜像，也支持压缩和多个虚拟机快照。快照模式可以把写入重定向到临时存储；虚拟机快照则在特定约束下保存 CPU 状态、内存（RAM）、设备状态和可写磁盘内容。[5] 选择不同，客户机的运维方式也随之变化。

部署 QEMU 时，-drive 或 -blockdev 配置需要认真规划。存储后端决定了机器如何读写数据，缓存模式（cache mode）、镜像格式、快照的具体行为、宿主文件系统行为和备份路径都应纳入设计评审。这些选择会直接影响客户机的延迟、数据持久性，以及意外故障时的表现。

按实际需求评估 QEMU

评估 QEMU 时，“快”与“简单”都过于笼统，涵盖了差异很大的需求。逐项确认需要哪些能力，才能判断它是否合适：

1. 需要跨架构运行时，重点考察 TCG。[2]
2. 需要在 Linux 上提高同架构执行性能时，通常使用 KVM 加速，QEMU 仍负责机器配置与设备建模。[1][3][7]
3. 需要可重复的设备与板级建模时，重点考察设备和机器模型。相关配置虽然繁多，却正是它的价值所在。[1][6]
4. 需要编排和生命周期控制时，重点考察 QMP 及其与上层管理工具的集成。[4]
5. 需要存储实验、快照或镜像可移植性时，应把块层与镜像格式的选择列为架构设计的主要问题。[5]

同一个项目可以满足这些不同需求。笼统地将其归为“虚拟机用途”，设计就容易疏漏：需要仿真时却预设有硬件加速，凭习惯选择磁盘格式，事后才接入管理 API，直到生产环境出现差异才注意到设备模型的影响。

结语

QEMU 持续发挥作用，是因为它让机器各部分的配置和分工都清晰可见。开发者和运维人员需要说明：CPU 指令采用软件翻译还是硬件加速，设备采用仿真建模还是直通，控制操作如何经由协议完成，存储配置又有哪些明确约定。逐项说明这些选择需要花费功夫，也让团队准确掌握自己正在搭建的机器。

对 2026 年使用 QEMU 的团队来说，可以先把各部分的分工记录下来。重视可移植性，就说明 TCG 的行为和目标架构支持情况；重视速度，就记录所用加速器，以及哪些部分仍在 QEMU 用户态运行。重视运维，就从一开始规划 QMP 与管理工具的配合；重视可恢复性，就在接受默认值前，按架构要求审视磁盘镜像和块后端的选择。

用 QEMU 运行客户机，也是在明确客户机、宿主机、存储、设备与运维人员之间的协作约定，并让这些约定可以逐一检查。

来源

1. QEMU documentation，"System Emulation: Introduction"。
2. QEMU documentation，"Emulation"。
3. Linux kernel documentation，"The Definitive KVM (Kernel-based Virtual Machine) API Documentation"。
4. QEMU documentation，"QEMU Machine Protocol Specification"。
5. QEMU documentation，"Disk Images"。
6. QEMU documentation，"Device Emulation"。
7. Ubuntu Server documentation，"QEMU"。
8. WordPress 托管的 2007 年 Fabrice Bellard 照片。