nova-compute卡在BUILD状态本质是libvirt未成功启动QEMU domain，需重点检查libvirtd状态、KVM支持、磁盘空间、SELinux权限及placement资源上报是否正常。
查 nova-compute 日志里有没有 “build instance” 后的卡点
虚拟机卡在 BUILD 状态，本质是 nova-compute 没能完成实例创建的最后一步——调用 libvirt 启动 domain。这时候它通常已经从 Glance 下载完镜像、从 Neutron 获取了端口、也分配好了磁盘，但就是没把 QEMU 进程拉起来。
直接看日志最有效：
journalctl -u nova-compute --since "10 minutes ago" | grep -A 5 -B 5 "build instance.*[a-f0-9\-]\{36\}"
重点盯三类输出：
- 出现
Failed to spawn instance+ 具体错误（比如libvirtError: internal error: process exited while connecting to monitor）→ 通常是 KVM/QEMU 启动失败 - 卡在
Waiting for instance to boot或反复重试get_power_state→ libvirt 连接正常，但虚拟机根本没真正启动 - 日志停在
Preparing image或Attaching volumes→ 问题出在 Glance 镜像下载慢、Cinder 卷挂载超时或磁盘空间不足
确认 libvirt 和 hypervisor 是否就绪
nova-compute 启动虚拟机前必须连上本地 libvirtd，并验证宿主机支持的虚拟化能力。这两步失败，BUILD 就永远不往下走。
手动验证命令：
- 检查 libvirtd 是否运行：
systemctl status libvirtd；若 inactive，先systemctl start libvirtd - 确认当前用户能访问 socket：
sudo -u nova virsh list --all；报Permission denied？检查/etc/libvirt/libvirtd.conf中unix_sock_group = "libvirtd"和nova用户是否在该组 - 验证 CPU 虚拟化支持：
egrep -c '(vmx|svm)' /proc/cpuinfo；返回 0 表示不支持 KVM，需强制设virt_type = qemu在[libvirt]段
特别注意：Kolla 部署下，libvirtd 可能在容器里，得进容器查；源码部署则直接查宿主机。
看 placement 和数据库里计算节点资源是否“假可用”
调度器选中某台 compute 后，nova-compute 会向 placement 上报资源使用，但上报失败或延迟会导致它“以为自己还有余量”，实际却因资源冲突无法创建。
快速判断方法：
- 执行
openstack hypervisor show，对比vcpus_used/vcpus、memory_mb_used/memory_mb；如果已用接近 100%，但nova-compute日志没报资源不足，可能是 placement 数据滞后 - 手动触发上报：
sudo -u nova nova-manage cell_v2 discover_hosts --verbose（Train+ 版本），或检查placementAPI 是否可通：curl -H "OpenStack-API-Version: placement 1.34" http://controller:8780/resource_providers - 查数据库残留：
mysql -unova -p -e "SELECT host, task_state FROM nova.instances WHERE host='；如果有大量' AND vm_state='building';" task_state = spawning且长期不更新，说明上次创建卡死没清理干净
别漏掉磁盘和 SELinux 这两个静默杀手
很多 BUILD 卡住根本不出错日志，是因为写磁盘失败或权限被拦，系统默认不报详细原因。
- 根分区或
/var/lib/nova/instances所在磁盘满？运行df -h / /var/lib/nova；local_gb不足也会让 scheduler 误判，但nova-compute启动时不会拒绝，而是卡在镜像解压或磁盘格式化阶段 - SELinux 强制启用时，
nova进程可能被禁止访问/var/lib/libvirt/images/或/dev/kvm；临时测试：setenforce 0，再试创建；若恢复，需打对应策略：ausearch -m avc -ts recent | audit2why - 检查
/var/log/libvirt/qemu/下对应 instance 的日志文件（命名如instance-00000001.log），这里常有 QEMU 启动失败的原始错误，比如Could not open '/dev/kvm': Permission denied
最麻烦的是那些不报错、也不推进的状态——往往不是代码逻辑问题，而是底层资源不可见或被策略锁死。动手前先看磁盘、SELinux、libvirt socket 权限，比翻三天 nova 日志更省时间。
