KVM GPU直通与单节点K8s监控
内容提要
本文记录在KVM虚拟机中直通8块H800 GPU和4块NVSwitch，并在单节点K8s中运行GPU Operator与Prometheus监控的排障过程。主要问题包括：黑屏与PCI资源不足，需改用非安全启动OVMF并将pci-hole64-size增至2048G；IP不可达因MAC变更导致DHCP绑定失效；还需配置NUMA与vCPU绑定。最后通过ServiceMonitor标签匹配，使DCGM指标成功接入Prometheus。
延伸解读
多GPU直通：优先排查OVMF与PCI资源
文章指出，多GPU直通时黑屏和PCI I/O区域无效的常见原因是OVMF安全启动和64位PCI hole过小。作者通过改用非安全版OVMF并将pci-hole64-size增至2048G解决了问题。这提示我们，在驱动报错前，应先检查虚拟化层配置，尤其是Q35芯片组的PCI资源分配，避免过早归咎于驱动。
网络故障：MAC地址变更导致DHCP绑定失效
虚拟机IP不可达的一个隐蔽原因是网卡MAC地址变化，导致DHCP租约不匹配。作者通过恢复旧MAC地址使IP恢复。这提醒运维人员，当网络异常时，除了检查路由和防火墙，还应核对libvirt XML中的MAC配置与DHCP租约是否一致，避免因小失大。
NUMA与vCPU绑定：影响性能的关键配置
文章将vCPU分组绑定到对应NUMA节点，并按NUMA本地性放置GPU。虽然这些配置不决定虚拟机能否启动，但作者强调应在早期做好，以确保实际工作负载运行时的性能。对于多GPU和NVSwitch环境，NUMA亲和性对避免跨节点访问延迟至关重要。
监控集成：ServiceMonitor标签匹配易忽略
DCGM指标接入Prometheus时，作者发现ServiceMonitor的release标签必须与Prometheus的release标签匹配，否则指标无法被采集。通过手动添加标签后，DCGM指标成功查询。这提醒我们，在K8s监控栈中，标签选择器是常见故障点，部署后应验证ServiceMonitor是否被正确发现。
Q&A
在KVM虚拟机中直通多块GPU时，出现黑屏和PCI资源不足的问题，应该如何解决？
需要将OVMF切换为非安全启动版本，并将Q35的pci-hole64-size增加到2048G。具体配置：使用/usr/share/edk2/ovmf/OVMF_CODE.cc.fd，并添加QEMU参数-global q35-pcihost.pci-hole64-size=2048G。
KVM虚拟机IP地址不可达，可能是什么原因？如何修复？
可能是网卡MAC地址变更导致DHCP绑定失效。恢复原来的MAC地址（如52:54:00:a9:a2:11）即可恢复IP（如192.168.122.146）。
在单节点K8s中，如何让Prometheus采集到DCGM的GPU监控指标？
需要确保DCGM Exporter的ServiceMonitor带有与Prometheus匹配的release标签。例如执行：kubectl -n gpu-operator label servicemonitor nvidia-dcgm-exporter release=kube-prometheus-stack --overwrite。
在KVM虚拟机中直通8块H800 GPU和4块NVSwitch，需要做哪些NUMA和vCPU绑定配置？
将vCPU分成两组并绑定到对应的NUMA节点，同时根据NUMA本地性放置GPU。内存设置为256GB（268435456 KiB）。
在无法直接访问公网的机器上，如何为containerd配置代理以拉取镜像？
创建/etc/systemd/system/containerd.service.d/http-proxy.conf文件，设置HTTP_PROXY和HTTPS_PROXY环境变量，并配置NO_PROXY排除内部地址。例如：HTTP_PROXY=http://100.64.0.5:8888，NO_PROXY=127.0.0.1,localhost,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10。
如何验证GPU直通、K8s和监控是否正常工作？
在GPU侧，运行nvidia-smi -L、nvidia-smi topo -m、nvidia-smi nvlink -s检查设备、拓扑和NVLink状态；在K8s侧，运行kubectl get nodes -o wide和kubectl get pods -A；在Prometheus侧，查询DCGM指标如curl http://127.0.0.1:9090/api/v1/query?query=DCGM_FI_DEV_SM_CLOCK。
