vcpupin vm-name vcpu-id pcpu-id 是唯一可靠的一对一绑定方式，因其直接调用 pthread_setaffinity_np 将指定 vCPU 线程严格限定在单个物理 CPU 核上，避免范围写法（如 6-8）导致的多核可选不确定性。
必须用 vcpupin 命令逐个指定 vCPU 到单个物理 CPU 核，不能靠范围写法（如 6-8）或掩码自动推导——否则不是“一对一”，只是“多选一”。
为什么 vcpupin vm-name vcpu-id pcpu-id 是唯一可靠的一对一方式
Libvirt 的 vcpupin 命令底层调用的是 pthread_setaffinity_np，它接受一个 CPU ID 列表（哪怕只传一个），并将其设为该 vCPU 线程的亲和性掩码。当你写 virsh vcpupin myvm 0 28，就等价于把 vCPU 0 的掩码设为 1 ，强制它只能在物理核 28 上运行。
常见误区是用 virsh vcpupin myvm 0 28-31：这会让 vCPU 0 在 28/29/30/31 四个核中任意调度，完全违背“一对一”目标；emulatorpin 只控制 QEMU 主进程（即 I/O 线程），不作用于 vCPU 线程，别混用。
- 确认宿主机物理核编号：用
lscpu或virsh capabilities查看cpuid实际值，注意超线程（SMT）下cpuid=0和cpuid=16可能是同一物理核的两个逻辑线程 - 避免跨 NUMA 节点：用
numactl --hardware查节点分布，vCPU 0 和内存最好同属node 0，否则绑定再准也扛不住远程内存延迟 - 绑定前确保虚拟机已启动：
vcpupin不支持离线状态操作，--config参数仅用于写入 XML，不立即生效
如何验证是否真的一对一绑死
运行 virsh vcpuinfo vm-name 后，关键看两列：CPU（当前正在跑的物理核）和 CPU Affinity（允许跑的核）。如果是一对一成功，CPU Affinity 应显示单个 y（比如 y 在第 29 位），且 CPU 列稳定显示同一个数字（如始终是 28），而不是跳变。
更底层验证：进宿主机查 QEMU 进程的线程亲和性：ps -eL | grep qemu 找到对应 vCPU 的 LWP PID，再执行 taskset -c -p <lwp-pid></lwp-pid>。输出应为纯数字（如 28），而非范围或十六进制掩码。
- 若
CPU Affinity显示全y（如yyyy...），说明没生效或被覆盖，检查是否用了--live但虚拟机未运行 - 若
CPU列数字跳变，大概率是绑了范围（如28-31）或宿主机开了isolcpus但没预留核心，导致内核强行迁移 -
taskset输出如果是0x10000000这类十六进制，需转成二进制数位确认是否只有一位为 1
让绑定永久生效：必须改 XML，且避开 emulatorpin 的干扰
临时绑定重启即失效。要持久化，必须编辑虚拟机 XML：virsh edit vm-name，在 <vcpu placement="static"></vcpu> 下方插入 <cputune></cputune> 块：
<cputune> <vcpupin vcpu='0' cpuset='28'/> <vcpupin vcpu='1' cpuset='29'/> <vcpupin vcpu='2' cpuset='30'/> <vcpupin vcpu='3' cpuset='31'/> </cputune>
注意：cpuset 必须是单个数字（如 '28'），不能写 '28-31' 或 '28,29'；vcpu 索引从 0 开始，必须与 vcpuinfo 中的 VCPU 编号一致。
- 改完 XML 后，必须
virsh define（或保存退出自动生效），再virsh shutdown && virsh start才真正加载新配置 - 不要同时配置
<emulatorpin></emulatorpin>：它会干扰 vCPU 线程调度，尤其当 emulator 和 vCPU 被绑到不同 NUMA 节点时，I/O 反而成为瓶颈 - XML 中若存在
<numatune></numatune>，务必与vcpupin的物理核所属节点一致，否则 libvirt 可能静默忽略绑定
最易被忽略的是：即使 XML 写对、virsh vcpuinfo 显示正常，如果宿主机开启了 intel_idle.max_cstate=1 或禁用了 C-states，某些 CPU 核可能无法进入低功耗状态，导致调度器误判负载而绕过绑定——这种问题得查 dmesg | grep -i "sched" 看是否有迁移警告。
