kvm/qemu不支持物理numa拓扑完全透传，vnuma需通过cpus、numa: 1和affinity协同配置实现；宿主机须≥2 numa节点，vcpu数须整除单节点cpu数，且affinity必须全落在同一物理节点内。
不能直接“完全透传”物理 NUMA 拓扑给虚拟机——这是个常见误解。KVM/QEMU 不支持把宿主机的 node0、node1 原样暴露为虚拟机内的 numa_node0、numa_node1。所谓“透传”，实际是通过 vNUMA 模拟 + CPU/内存绑定，让虚拟机操作系统感知到一个逻辑上合理、与底层物理拓扑对齐的 NUMA 结构。
为什么 numa=1 在 PVE8 里常导致虚拟机卡 BIOS
在 Proxmox VE 8 中，手动往 /etc/pve/qemu-server/100.conf 加 numa=1 是无效甚至有害的操作：
-
numa=1是 QEMU 的旧参数，PVE8 已弃用，它不触发 vNUMA，只强制启用 NUMA-aware 内存分配，但没配节点拓扑，内核启动时找不到有效节点描述，卡在 early boot 阶段 - PVE8 的 vNUMA 控制必须通过
cpus、numa（小写）和hostpci等组合参数协同生效，单独加任何一项都可能被校验拒绝或静默忽略 - 宿主机若只有单 NUMA 节点（
numactl --hardware显示available: 1 nodes），强行启 vNUMA 会失败；PVE 也不会报错，而是降级为普通 NUMA-unaware 分配
正确启用 vNUMA：必须满足三个硬条件
vNUMA 不是开关，而是一组资源约束策略。以下三点缺一不可：
- 宿主机至少有两个物理 NUMA 节点（
numactl --hardware | grep "available:"输出应为available: 2 nodes或更多） - 虚拟机 vCPU 总数必须能被整除进某个物理节点的 CPU 数量（例如宿主机 node0 有 8 个逻辑 CPU，则 vCPU 可设为 4、8、16，但不能设为 6 或 10）
- 必须显式指定 CPU 绑定策略：
cpus: 8+affinity: 0,1,2,3,4,5,6,7（对应 node0 上所有逻辑 CPU 编号），且这些编号必须全部落在同一个物理 NUMA 节点内（查numactl --hardware的node X cpus:字段确认）
示例（PVE8 配置片段）：
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
cpus: 8 numa: 1 affinity: 0,1,2,3,4,5,6,7 memory: 16384
注意：numa: 1 这里是 PVE 的 YAML 键名，不是 QEMU 的 -numa 参数；它告诉 PVE 启用 vNUMA 拓扑生成，而非传递 raw 参数。
验证虚拟机是否真拿到了 vNUMA
进虚拟机后别只信 lscpu ——它可能显示 NUMA node(s): 1 即使你配了 vNUMA。真正权威的检查方式是：
- 运行
numactl --hardware：应看到多个node X cpus:行，且每个节点的 CPU 列表与你配置的affinity子集一致 - 检查
/sys/devices/system/node/：目录下应有node0、node1等子目录，且node0/cpulist内容匹配你绑定的逻辑 CPU 号 - 运行
cat /proc/cpuinfo | grep "physical id\|core id\|processor" | head -20，观察 processor 编号是否按节点分组连续出现（vNUMA 正常时，node0 的 vCPU 通常映射为连续低编号）
如果 numactl --hardware 在虚拟机里只显示一个节点，说明 vNUMA 未生效——大概率是宿主机 affinity 指定了跨节点的 CPU，或 PVE 版本低于 8.1（vNUMA 支持在 8.1 才趋于稳定）。
最易被忽略的一点：vNUMA 生效的前提是虚拟机内核必须启用 CONFIG_NUMA 和 CONFIG_ACPI_NUMA。主流发行版默认开启，但如果你用的是自定义裁剪内核或某些实时内核变种，得手动确认。否则，哪怕 PVE 配置全对，虚拟机也只会当自己跑在 UMA 系统上。
