cgroups v2 的 cpu.max 能硬性限制 QEMU 虚拟机 CPU 上限，因其直接作用于内核调度器，通过配额+周期机制统一管控主线程及所有 vCPU/IO 线程；而 cpulimit 依赖信号干预，在 QEMU 处于 D 状态时失效，且无法捕获 clone 创建的 vCPU 线程。
cpulimit 对虚拟机进程完全无效，systemd CPUQuota 仅对服务单元生效，真正能硬性限制虚拟机（如 qemu-system-x86_64 进程）CPU 占用上限的，只有 cgroups v2 的 cpu.max 配置——它直接作用于内核调度器，不依赖信号干预，也不会被子进程绕过。
为什么不能用 cpulimit 限制 KVM/QEMU 虚拟机
cpulimit 本质是轮询发送 SIGSTOP/SIGCONT，但 QEMU 主进程大量时间处于 D 状态（不可中断睡眠），尤其是执行 I/O 或等待 vCPU 退出时；此时 ptrace 无法 attach，cpulimit 直接失效。更关键的是：QEMU fork 出的 vCPU 线程（如 qemu:cpu/0）和 IO 线程各自独立调度，cpulimit -p 只能锁住主进程，对真实吃 CPU 的 vCPU 线程毫无约束。
常见错误现象：
- 运行
cpulimit -e qemu-system-x86_64 -l 30后，top里%CPU仍显示 200%+（双核满载） - 用
ps -o pid,comm,state -C qemu-system-x86_64发现大量线程状态为D - 即使加
-r递归参数，也无法捕获由clone()创建的 vCPU 线程（它们不属于传统父子进程树）
正确做法：用 cgroups v2 绑定并限频整个 QEMU 进程组
必须把 QEMU 启动的所有线程（包括主线程、vCPU、IO、worker）统一塞进一个 cgroup，再设 cpu.max。步骤如下：
- 确认系统启用 cgroups v2：
mount | grep cgroup2，输出应含cgroup2 on /sys/fs/cgroup type cgroup2 - 创建控制组：
sudo mkdir -p /sys/fs/cgroup/vm-qemu-nginx - 设 CPU 配额（例如限制为 1 核的 60%，即每 100ms 最多用 60ms）：
echo "60000 100000" | sudo tee /sys/fs/cgroup/vm-qemu-nginx/cpu.max - 找出 QEMU 进程的
pid（不是ps aux | grep qemu那个，而是pgrep -f 'qemu.*nginx'返回的主 PID） - 将整个线程组写入：
echo $PID | sudo tee /sys/fs/cgroup/vm-qemu-nginx/cgroup.procs（注意是cgroup.procs，不是tasks；后者只写单线程，前者自动包含所有线程）
验证是否生效：cat /sys/fs/cgroup/vm-qemu-nginx/cpu.stat 查看 usage_usec 是否稳定在设定带宽内；systemd-cgtop 也能实时看到该组总 CPU 消耗。
如果虚拟机由 libvirt + virt-manager 管理
手动操作 cgroup 极易被 libvirt 覆盖（它会定期重置 cgroup 层级）。必须改用 libvirt 原生支持的 cgroups v2 配置：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 编辑虚拟机 XML：
virsh edit nginx-vm - 在
<domain>根节点下添加：
<cputune>
<vcpupin vcpu='0' cpuset='0-1'/>
<emulatorpin cpuset='0-1'/>
<quotas>
<vcpu_quota>60000</vcpu_quota>
<vcpu_period>100000</vcpu_period>
</quotas>
</cputune>
其中 vcpu_quota 和 vcpu_period 会被 libvirt 映射为 cgroups v2 的 cpu.max。重启虚拟机后生效，且不会被覆盖。
注意：vcpu_quota 是 per-vCPU 限额。若虚拟机配置了 2 个 vCPU，又想总 CPU 不超 60%，则需设 vcpu_quota="30000"（30% × 100000）。
别踩 taskset 和 renice 的坑
taskset -c 0-1 qemu-system-x86_64 ... 只是绑核，不控使用率——绑在两核上照样可以跑满 200%；renice -n 19 更是徒劳，QEMU 在空闲宿主机上依然会吞光所有可用 CPU 时间片。这两个命令和「限制使用率」根本不是一回事。
真正难的不是设限，而是确认所有 vCPU 线程都被纳入同一 cgroup——QEMU 的线程模型复杂，cgroup.procs 写入主 PID 是唯一可靠方式；漏掉任意一个 vCPU 线程，它就会脱离配额自由狂奔。
