Go语言QEMU与libvirt封装库：纯Go虚拟化管理实践

1. 项目概述：为什么两个 Go 语言封装库值得单独发一篇博客？

最近在 DigitalOcean 的开源频道里看到一篇标题很“安静”的公告——《Open Source at DigitalOcean: Introducing go-qemu and go-libvirt》。没有“重磅发布”“颠覆性升级”这类营销词，连个感叹号都没用。但作为在虚拟化底层摸爬滚打八年、亲手写过 libvirt XML 模板校验器、调试过 QEMU 启动时卡在 -S 冻结状态的从业者，我点进去第一眼就坐直了：这不是又一个玩具级 wrapper，而是真正踩在生产痛点上长出来的工具。

go-qemu 和 go-libvirt 这两个库，核心关键词就是三个字： Go 语言 + QEMU + libvirt 。它们不是替代 QEMU 或 libvirtd，而是用 Go 重写了与这两者交互的“手”，让 Go 程序员不用再靠 exec.Command("virsh", "list", "--all") 这种字符串拼接+正则解析的野路子去管理虚拟机，也不用在 cgo 和 C 头文件之间反复横跳、被 #include <libvirt/libvirt.h> 编译失败折磨到凌晨三点。

我试过用 go-qemu 启动一个 Tiny Core Linux 镜像——从读取磁盘镜像、构造 QEMU 命令行参数、设置 CPU topology、挂载 9p 共享目录，到捕获串口输出并实时打印到终端，整个过程只用了 87 行 Go 代码，且全程类型安全。而用传统方式？你得先查 qemu-system-x86_64 --help 输出，再手动拼 -smp 2,cores=2,threads=1,sockets=1 ，稍有不慎线程数设错，Guest OS 就识别成单核；更别说 Windows Guest 下 HVM vs SVM 的 CPU flag 适配问题。 go-qemu 的价值，是把 QEMU 这个命令行巨兽，变成 Go 里一个可组合、可测试、可 debug 的 struct。

至于 go-libvirt ，它解决的是另一个更隐蔽的痛：libvirt 的 Go 绑定长期处于“半废弃”状态。官方 libvirt-go 库依赖 CGO，编译链脆弱，交叉编译基本放弃治疗；社区版又五花八门，有的只支持连接，不支持域生命周期管理；有的连 Domain.GetState() 返回值都解析错。而 go-libvirt 直接绕过 CGO，纯 Go 实现 libvirt 的 RPC 协议（基于 UNIX socket 或 TCP），这意味着：你在 ARM64 的 Orange Pi PC 上编译出的二进制，能直接连到 x86_64 服务器上的 libvirtd；你在 Windows 开发机上写的管理脚本， GOOS=linux GOARCH=arm64 go build 一把就能扔进树莓派集群跑。这背后不是炫技，是真实业务场景倒逼出来的——DigitalOcean 自己的云平台控制面，需要统一调度 KVM、QEMU、LXC 多种后端，而 Go 是其主力语言。

所以这篇博客不讲“什么是 QEMU”，也不教“怎么安装 Go”，它面向的是已经知道 qemu-img create -f qcow2 disk.qcow2 10G 是干啥、也写过 virsh define vm.xml && virsh start vm 的人。如果你正面临这些场景：

• 用 Go 写 CI/CD 流水线，需要动态启停测试用虚拟机；
• 在边缘设备（如 Orange Pi）上做轻量虚拟化网关，但不想装完整 libvirt；
• 开发云管平台，需要避免 CGO 带来的部署复杂度；
• 或者只是厌倦了每次改一行 XML 就要 virsh define 再 virsh destroy && virsh start 的循环……
  那这两个库，就是你现在最该了解的“隐形基础设施”。

2. 核心设计思路：为什么不用 CGO？为什么是纯 Go 实现？

2.1 放弃 CGO 不是情怀，是运维成本的硬约束

先说结论： go-libvirt 完全不依赖 CGO，go-qemu 也仅在极少数可选功能（如 KVM 加速检测）中调用少量系统调用，主体逻辑 100% 纯 Go。 这个决策背后，是 DigitalOcean 工程师在真实生产环境里被 CGO 反复毒打后的理性选择。

我们来算一笔账。假设你用官方 libvirt-go （CGO 版本）开发一个虚拟机管理服务：

我亲身经历的一个案例：去年为某金融客户做私有云网关，要求 ARM64 设备上运行虚拟防火墙。他们提供的硬件只有 2GB RAM，且禁止安装任何非白名单软件。用 CGO 方案？光是交叉编译 libvirt-go 就卡在 libxml2 版本兼容上三天；而用 go-libvirt ，我本地 GOARCH=arm64 go build -ldflags="-s -w" 生成二进制，scp 过去 chmod +x && ./gateway 就启动成功。 纯 Go 的最大优势，不是性能，而是“确定性”——你知道构建产物是什么，部署行为是什么，故障边界在哪里。

2.2 go-qemu 的分层抽象：从命令行到结构体的进化

QEMU 本身是个典型的“Unix 哲学”工具：功能强大，但接口是字符串。 go-qemu 的设计，本质是一次对 QEMU CLI 的“面向对象重构”。它没试图封装所有 200+ 个参数，而是聚焦高频、易错、强类型的场景，分三层实现：

• Layer 1：参数构造器（Builder Pattern）
  所有 QEMU 启动参数被建模为 Go struct 字段。例如 CPU 配置：

  cpu := qemu.CPU{
      Model:   "host",
      Cores:   2,
      Threads: 1,
      Sockets: 1,
      Features: []string{"+vmx", "+smep"}, // 显式控制 CPU flag
  }
  

  对应命令行 -cpu host,cores=2,threads=1,sockets=1,+vmx,+smep 。这里的关键是： Features 字段强制要求显式声明 ，避免传统做法中遗漏 +kvm_hv 导致 Windows Guest 蓝屏。

• Layer 2：设备拓扑管理器（Topology Manager）
  解决 QEMU 设备地址冲突这个经典坑。比如你同时加一块 virtio-blk 磁盘和一块 virtio-net 网卡，传统写法：

  -drive if=virtio,file=disk.qcow2 \
  -netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
  -device virtio-net-pci,netdev=net0
  

  但若没指定 bus=pci.0,addr=0x3 ，QEMU 可能随机分配地址，导致 Guest 中设备顺序错乱。 go-qemu 则内置 PCI 总线地址分配器：

  dev := qemu.NewVirtioBlockDevice("/path/to/disk.qcow2")
  dev.SetBusAddress(qemu.PCIAddress{Bus: "pci.0", Slot: 0x3}) // 强制固定
  

• Layer 3：生命周期与事件总线（Event Bus）
  QEMU 启动后，如何知道 Guest 是否已启动完毕？传统方案是轮询 qemu-img info 或解析 ps aux 。 go-qemu 提供 qmp （QEMU Monitor Protocol）客户端，直接监听 QMP 事件：

  qmpConn, _ := qemu.NewQMPConnection("/tmp/qmp-sock")
  qmpConn.On("POWERDOWN", func(e *qmp.Event) {
      log.Println("Guest OS initiated shutdown")
      // 触发清理逻辑
  })
  

这种分层，让开发者可以按需使用：简单场景用 Builder 快速启动；复杂场景用 Topology Manager 精确控制；高可靠性场景接入 QMP 事件总线。 它不追求“大而全”，而是让每个层次都解决一类明确的问题。

2.3 为什么不自己造轮子？libvirt 和 QEMU 的定位差异

常有人问：“既然有 libvirt，为什么还要 go-qemu？” 这是个好问题，答案藏在架构分层里。

• libvirt 是“虚拟化管理层” ：它提供统一 API 抽象 KVM/QEMU/Xen/LXC，负责资源配额、网络定义、存储池管理、迁移等跨后端能力。但它对 QEMU 的控制是“声明式”的（XML 描述期望状态），实际执行仍委托给 QEMU 进程。

• QEMU 是“虚拟化执行层” ：它直接操作 CPU、内存、设备模拟，对性能、实时性、硬件特性（如 Intel VT-d IOMMU 直通）有绝对控制权。当你需要微秒级中断延迟、精确的 CPU topology 暴露、或绕过 libvirt 限制做定制化设备模拟时，必须直连 QEMU。

go-libvirt 和 go-qemu 的共存，恰恰反映了现代云架构的分层思想：

• 控制面（Control Plane）用 go-libvirt 管理大规模虚拟机生命周期，保证策略一致性；
• 数据面（Data Plane）用 go-qemu 构建高性能网络功能虚拟化（NFV）组件，如 vRouter、vFW，直通物理网卡，绕过 libvirt 的抽象开销。

举个实例：DigitalOcean 的 Droplet 快照功能，后端用 go-libvirt 调用 virDomainSnapshotCreateXML() 创建快照元数据；而其内部的“实时迁移加速模块”，则用 go-qemu 直接向 QEMU 发送 migrate_set_downtime QMP 命令，将停机时间压到 50ms 以内——这是 libvirt XML 无法表达的精细控制。

3. 核心细节解析：从零开始搭建一个可运行的 QEMU + libvirt 管理示例

3.1 环境准备：三步完成最小可行环境

别被“虚拟化”吓住，我们用最简路径验证。以下步骤在 Ubuntu 22.04 / Debian 12 / CentOS Stream 9 上实测通过，全程无需 root 权限（除安装基础包外）。

Step 1：安装宿主机依赖

# Ubuntu/Debian
sudo apt update && sudo apt install -y qemu-kvm libvirt-daemon-system virtinst cpu-checker

# CentOS/RHEL
sudo dnf install -y @virtualization qemu-kvm libvirt virt-install

# 启用并启动 libvirtd（仅首次需要）
sudo systemctl enable --now libvirtd

提示： cpu-checker 用于验证 KVM 支持，运行 kvm-ok 输出 KVM acceleration can be used 即表示 OK。若提示 INFO: /dev/kvm does not exist ，需检查 BIOS 中是否开启 Intel VT-x/AMD-V。

Step 2：配置无密码 libvirt 连接（关键！）
默认 virsh 需要 root 或 libvirt 用户组权限。为避免后续 Go 程序权限问题，创建用户会话连接：

# 将当前用户加入 libvirt 组
sudo usermod -a -G libvirt $(whoami)
# 重新登录或重启终端使组生效
newgrp libvirt

# 验证连接
virsh -c qemu:///session list --all  # 应返回空列表，无报错即成功

注意： qemu:///session 是用户会话模式，所有虚拟机仅对当前用户可见，无需 sudo； qemu:///system 是系统模式，需 root 权限。生产环境推荐 system 模式，但开发调试用 session 模式更安全。

Step 3：准备 Tiny Core Linux 测试镜像
Tiny Core 是极简 Linux 发行版，镜像仅 16MB，启动快，完美验证基础功能：

# 下载并解压（国内用户可用清华源）
wget https://repo.tinycorelinux.net/14.x/x86/release/Core-current.iso
# 转换为 qcow2 格式（支持快照）
qemu-img convert -f raw -O qcow2 Core-current.iso core.qcow2
# 设置镜像为可写（ISO 默认只读）
qemu-img resize core.qcow2 +1G

3.2 go-qemu 实战：5 分钟启动一个可交互的 Tiny Core

现在用 go-qemu 启动 Tiny Core，并通过串口与之交互。新建 main.go ：

package main

import (
    "context"
    "fmt"
    "log"
    "os/exec"
    "time"

    "github.com/digitalocean/go-qemu"
)

func main() {
    // 1. 构造 QEMU 实例
    vm := qemu.NewQEMUMachine("tiny-core-test").
        WithArch(qemu.ArchX8664).
        WithMemory(512).           // 512MB RAM
        WithCPU(qemu.CPU{
            Model: "host",         // 使用宿主 CPU 特性
            Cores: 1,
        }).
        WithBootOrder(qemu.BootOrder{
            Devices: []qemu.BootDevice{qemu.BootDeviceCDROM},
        })

    // 2. 添加磁盘（Tiny Core ISO）
    vm.AddDrive(qemu.Drive{
        File:     "core.qcow2",
        Format:   "qcow2",
        Interface: qemu.InterfaceIDE,
        Media:    qemu.MediaCDROM,
    })

    // 3. 添加串口控制台（关键！用于交互）
    vm.AddSerial(qemu.Serial{
        Type: qemu.SerialTypeChardev,
        Chardev: qemu.Chardev{
            Backend: qemu.ChardevBackendStdio,
            Signal:  true, // 捕获 Ctrl+C
        },
    })

    // 4. 启动并等待
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    cmd, err := vm.Start(ctx)
    if err != nil {
        log.Fatal("Failed to start QEMU: ", err)
    }

    // 5. 捕获 stdout 并实时打印（模拟串口终端）
    go func() {
        buf := make([]byte, 1024)
        for {
            n, _ := cmd.Stdout.Read(buf)
            if n > 0 {
                fmt.Print(string(buf[:n]))
            }
        }
    }()

    // 6. 等待进程结束（或手动 Ctrl+C）
    if err := cmd.Wait(); err != nil {
        log.Printf("QEMU exited with error: %v", err)
    }
}

编译并运行：

go mod init tiny-core-demo
go get github.com/digitalocean/go-qemu
go run main.go

你会看到 Tiny Core 启动日志飞速滚动，最后停在 tc@box:~$ 提示符。此时可输入 ls / 查看根目录，或 dmesg | head 看内核日志。 这就是一个真实的、可交互的虚拟机——没有 XML，没有 virsh，只有 Go 代码。

实操心得：若启动后黑屏无输出，大概率是串口配置问题。检查 AddSerial 中 Signal: true 是否启用，以及 Tiny Core ISO 是否支持 console=ttyS0 内核参数（可在 vm.AddKernelArgs("console=ttyS0") 中添加）。我第一次就栽在这儿，折腾半小时才发现 ISO 版本太老不支持。

3.3 go-libvirt 实战：用纯 Go 创建并管理虚拟机

接下来用 go-libvirt 替代上面的手动 QEMU 启动，走标准 libvirt 流程。新建 libvirt-demo.go ：

package main

import (
    "context"
    "fmt"
    "log"
    "time"

    "github.com/digitalocean/go-libvirt"
)

func main() {
    // 1. 连接到 libvirtd（用户会话模式）
    conn, err := libvirt.NewConnection("qemu:///session")
    if err != nil {
        log.Fatal("Failed to connect to libvirt: ", err)
    }
    defer conn.Close()

    // 2. 定义虚拟机 XML（精简版，仅核心字段）
    xml := `<domain type='kvm'>
      <name>tiny-core-libvirt</name>
      <memory unit='MiB'>512</memory>
      <vcpu placement='static'>1</vcpu>
      <os>
        <type arch='x86_64' machine='pc-q35-7.2'>hvm</type>
        <boot dev='cdrom'/>
      </os>
      <devices>
        <disk type='file' device='cdrom'>
          <driver name='qemu' type='qcow2'/>
          <source file='/full/path/to/core.qcow2'/>
          <target dev='hda' bus='ide'/>
          <readonly/>
        </disk>
        <serial type='pty'>
          <target port='0'/>
        </serial>
        <console type='pty'>
          <target type='serial' port='0'/>
        </console>
      </devices>
    </domain>`

    // 3. 创建并启动域
    domain, err := conn.DomainDefineXML(xml)
    if err != nil {
        log.Fatal("Failed to define domain: ", err)
    }
    defer domain.Free()

    if err := domain.Create(); err != nil {
        log.Fatal("Failed to start domain: ", err)
    }
    log.Println("Domain started successfully!")

    // 4. 等待 10 秒后关闭
    time.Sleep(10 * time.Second)
    if err := domain.Destroy(); err != nil {
        log.Printf("Warning: failed to destroy domain: %v", err)
    }
}

关键点解析：

• libvirt.NewConnection("qemu:///session") 使用用户会话，避免权限问题；
• XML 中 <boot dev='cdrom'/> 确保从光盘启动； <readonly/> 防止写入 ISO；
• <serial> 和 <console> 配置是获取串口输出的前提，否则 virsh console 会连不上；
• domain.Destroy() 是强制关机，如需优雅关机，应先 domain.Shutdown() 再轮询状态。

运行 go run libvirt-demo.go ，你会看到日志输出，同时执行 virsh -c qemu:///session list --all 可看到虚拟机短暂出现。 这证明 go-libvirt 已成功接管 libvirtd。

注意事项：XML 中的 source file 必须是 绝对路径 ，相对路径会导致 virsh 报错 cannot open disk image 。这是 libvirt 的硬性要求， go-libvirt 不做路径转换，需开发者自行处理（可用 filepath.Abs("core.qcow2") ）。

4. 实操过程深度拆解：参数选择、性能调优与避坑指南

4.1 QEMU 参数黄金组合：平衡启动速度与 Guest 兼容性

QEMU 启动参数繁多，但生产环境只需关注 5 个核心参数。 go-qemu 将它们封装为结构体字段，我们逐个分析其原理与取值逻辑：

避坑重点： cache=none 的前提条件
必须确保磁盘镜像文件系统支持 O_DIRECT （如 ext4/xfs），且文件未被其他进程锁定。若误用在 NTFS 挂载的 Windows 共享盘上，QEMU 会静默降级为 cache=writeback ，导致数据一致性风险。 go-qemu 在 Drive.Validate() 方法中会检查文件系统类型，建议在 vm.Start() 前调用：

if err := drive.Validate(); err != nil {
    log.Fatalf("Invalid drive config: %v", err) // 如：cache=none not supported on ntfs
}

4.2 libvirt 存储池实战：用 Go 动态创建 QCOW2 存储池

libvirt 的存储池（Storage Pool）是管理磁盘镜像的基石。 go-libvirt 提供完整 API，以下代码演示如何用 Go 创建一个基于目录的 QCOW2 存储池：

func createStoragePool(conn *libvirt.Connection, poolName, poolPath string) error {
    // 1. 创建存储池 XML
    poolXML := fmt.Sprintf(`
    <pool type='dir'>
      <name>%s</name>
      <target>
        <path>%s</path>
        <permissions>
          <mode>0755</mode>
        </permissions>
      </target>
    </pool>`, poolName, poolPath)

    // 2. 定义并启动存储池
    pool, err := conn.StoragePoolDefineXML(poolXML)
    if err != nil {
        return fmt.Errorf("define pool: %w", err)
    }
    defer pool.Free()

    if err := pool.Create(0); err != nil {
        return fmt.Errorf("create pool: %w", err)
    }

    // 3. 刷新以发现现有镜像
    if err := pool.Refresh(0); err != nil {
        return fmt.Errorf("refresh pool: %w", err)
    }

    // 4. 创建卷（Volume）- 即 QCOW2 镜像
    volXML := fmt.Sprintf(`
    <volume>
      <name>test-disk.qcow2</name>
      <capacity unit='G'>10</capacity>
      <target>
        <format type='qcow2'/>
        <permissions>
          <mode>0644</mode>
        </permissions>
      </target>
    </volume>`)
    
    vol, err := pool.StorageVolCreateXML(volXML, 0)
    if err != nil {
        return fmt.Errorf("create volume: %w", err)
    }
    defer vol.Free()

    log.Printf("Created volume: %s", vol.GetName())
    return nil
}

关键细节：

• pool.Create(0) 中的 0 表示“不自动启动”，需显式调用 pool.Build(0) 初始化文件系统；
• volXML 中 <capacity unit='G'>10</capacity> 创建稀疏文件，实际占用磁盘空间随写入增长；
• 若需预分配空间（避免碎片），改为 <allocation unit='G'>10</allocation> ，但创建时间变长。

实操心得：我曾在线上环境用此方法批量创建 100 个 20GB 卷，发现 pool.Refresh() 耗时达 12 秒。优化方案是：在 pool.Create() 后立即 pool.ListAllVolumes() 获取已有卷，避免全量扫描；新卷创建后单独 vol.GetInfo() 获取大小，而非依赖 Refresh() 。

4.3 跨平台编译陷阱：ARM64 设备上运行 QEMU 管理程序

Orange Pi PC 等 ARM64 设备是边缘虚拟化的热门选择，但编译 Go 程序时极易踩坑。以下是 go-qemu 在 ARM64 上的实操要点：

Step 1：确认宿主 QEMU 支持 ARM64 目标

# 在 Orange Pi 上检查
qemu-system-aarch64 --version  # 必须存在，且版本 ≥ 6.2
# 若不存在，需编译安装（Ubuntu 22.04 源中为 6.2，够用）
sudo apt install qemu-system-arm

Step 2：交叉编译 Go 程序（关键！）
不要在 ARM 设备上 go build （慢且易内存溢出），而是在 x86_64 开发机上交叉编译：

# 设置环境变量
export GOOS=linux
export GOARCH=arm64
export CGO_ENABLED=0  # 必须禁用 CGO！

# 编译（go-qemu 无 CGO 依赖，放心）
go build -ldflags="-s -w" -o manager-arm64 .

# scp 到 Orange Pi
scp manager-arm64 pi@orangepi:/home/pi/

Step 3：ARM64 特有参数适配
启动 ARM64 Guest 时， go-qemu 需指定机器类型和固件：

vm := qemu.NewQEMUMachine("arm64-vm").
    WithArch(qemu.ArchAArch64).
    WithMachine(qemu.Machine{
        Type: "virt",       // ARM64 通用虚拟机
        Version: "7.2",     // 与 QEMU 版本匹配
    }).
    WithFirmware(qemu.Firmware{
        Path: "/usr/share/qemu-efi-aarch64/QEMU_EFI.fd", // UEFI 固件路径
        SecureBoot: false,
    })

注意：ARM64 固件路径因发行版而异。Ubuntu 在 /usr/share/qemu-efi-aarch64/ ，Debian 在 /usr/share/AAVMF/ 。 go-qemu 不内置固件，需开发者自行确认路径并传入。我第一次在 Orange Pi 上运行失败，就是因为固件路径写错了，QEMU 报错 Could not load firmware 。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 QEMU 启动卡死排查：从日志到 QMP 的全链路诊断

QEMU 启动卡在某个环节是最高频问题。以下是系统化排查流程，按优先级排序：

进阶技巧：用 QMP 实时诊断
当常规日志不够用时，启用 QMP 监控：

// 启动 QEMU 时启用 QMP socket
vm.AddQMP(qemu.QMP{
    SocketPath: "/tmp/qmp.sock",
    Pretty:     true,
})

// 启动后连接 QMP 并发送命令
qmp, _ := qemu.NewQMPConnection("/tmp/qmp.sock")
defer qmp.Close()

// 查询当前状态
resp, _ := qmp.Execute("query-status")
fmt.Printf("Status: %+v\n", resp)

// 查询块设备信息
resp, _ = qmp.Execute("query-block")
fmt.Printf("Block devices: %+v\n", resp)

QMP 返回 JSON 结构化数据，比解析 qemu-img info 文本可靠得多。我曾用此法发现一块磁盘的 io_status 为 failed ，定位到是 NFS 存储后端网络抖动导致。

5.2 libvirt 连接失败： authentication failed 的真实原因

go-libvirt 连接报错 authentication failed 是新手最大拦路虎。这不是密码错误，而是 libvirt 的认证机制问题。根本原因有三：

1. 未启用 polkit 规则 （最常见）
   libvirt 默认用 polkit 做权限控制。需创建 /etc/polkit-1/rules.d/50-libvirt.rules ：

   // Allow users in libvirt group to manage libvirt without password
   polkit.addRule(function(action, subject) {
       if (action.id == "org.libvirt.unix.manage" &&
           subject.isInGroup("libvirt")) {
           return polkit.Result.YES;
       }
   });
   

   然后重启 sudo systemctl restart polkitd 。

2. libvirtd 配置未监听 socket
   检查 /etc/libvirt/libvirtd.conf ：

   unix_sock_group = "libvirt"    # 确保与用户组一致
   unix_sock_rw_perms = "0770"    # 权限必须包含组写
   auth_unix_ro = "none"          # 读操作免认证
   auth_unix_rw = "none"          # 写操作免认证（开发环境）
   

3. SELinux/AppArmor 限制 （CentOS/RHEL）
   临时禁用测试： sudo setenforce 0 。若恢复，需添加策略：

   # CentOS 8+
   sudo ausearch -m avc -ts recent | audit2why
   sudo audit2allow -a -M mylibvirt && sudo semodule -i mylibvirt.pp
   

实操心得：我在一台新装的 Rocky Linux 9 上调试了 3 小时，最终发现是 SELinux 的 virt_qemu_ga_t 类型被阻止。 ausearch -m avc -ts today 输出了 17 条拒绝日志， audit2why 一句提示就解决了。 永远先看 audit 日志，而不是猜。

5.3 性能瓶颈定位：CPU 占用 100% 的 3 个真相

当 go-qemu 启动的虚拟机 CPU 占用持续 100%，通常不是代码 bug，而是配置失当：

终极验证：用 perf 火焰图
在宿主上对 QEMU 进程采样：