Nova计算节点不管理宿主机，仅通过libvirt调用KVM；大规模宿主机调度由控制节点的nova-scheduler与Placement协同完成，计算节点需确保nova-compute稳定注册、资源上报准确及KVM配置正确。
直接说结论：Nova计算节点本身不“管理”宿主机，它只负责在本机上通过libvirt调用KVM启动/停止实例；所谓“管理大规模宿主机”，其实是控制节点上的nova-scheduler + Placement服务协同完成的资源调度，计算节点只需确保自身nova-compute稳定注册、资源上报准确、KVM配置无硬伤。
为什么nova-compute注册后总显示down或resource tracker报错
这是大规模部署中最常见的假性故障——表面是计算节点没起来，实际是控制节点无法确认它的资源状态。核心原因有三个：
-
nova-compute服务虽然运行着，但没成功向PlacementAPI上报资源（比如placement_url配错、token过期、网络不通） -
my_ip在/etc/nova/nova.conf里写成了127.0.0.1或内网不可达地址，导致nova-conductor无法反向连接该节点做健康检查 - 宿主机CPU不支持硬件虚拟化（
egrep -c '(vmx|svm)' /proc/cpuinfo返回0），却没在[libvirt]段显式设virt_type = qemu，造成libvirt初始化失败，nova-compute静默退出
验证方式：登录计算节点，执行nova-status upgrade check，重点看resource_providers和compute_nodes两项是否OK；再查journalctl -u openstack-nova-compute -n 50，找Failed to initialize driver或Unable to reach placement API类错误。
libvirt配置必须关掉listen_tcp和auth_tcp
很多人照着旧文档开libvirtd的TCP监听，以为这样能让控制节点远程操作，这是严重误区。Nova从Train版起完全弃用libvirt远程调用，所有操作都走本地UNIX socket（unix:///var/run/libvirt/libvirt-sock）。开着TCP监听反而会触发SELinux拒绝或防火墙拦截，导致nova-compute反复重连失败。
正确做法是确保/etc/libvirt/libvirtd.conf中这三行被注释或设为no：
listen_tls = 0 listen_tcp = 0 auth_tcp = "none"
然后重启libvirtd：systemctl restart libvirtd。顺手验证：virsh -c qemu:///system list能正常列出空列表，说明libvirt本地通信已通。
大规模场景下nova-compute性能瓶颈不在CPU，而在libvirt连接池和数据库心跳
单台计算节点挂载几十台虚拟机时，nova-compute进程常因频繁查询libvirt状态卡住，表现为日志里大量Timed out waiting for libvirt connection。这不是配置错误，而是默认连接池太小。
解决方法是在/etc/nova/nova.conf的[libvirt]段加两行：
[libvirt] # 增大libvirt连接池，避免并发查询阻塞 connection_uri = qemu:///system # 默认是1，改成5可显著降低超时率 connections = 5
同时，在[DEFAULT]段调高心跳间隔，减少对控制节点nova-conductor的无效轮询：
[DEFAULT] # 默认是60秒，大集群建议120~180秒 service_down_time = 180
改完重启openstack-nova-compute即可，无需动数据库或消息队列。
Placement资源同步延迟会导致调度到“已满”的宿主机
这是大规模环境最隐蔽的问题：明明某台宿主机内存已用95%，nova-scheduler却仍把它列为候选。根本原因是nova-compute上报资源给Placement不是实时的，而是每60秒一次（由resource_tracker_interval控制），且上报内容只含总量与已用值，不含瞬时负载。
临时缓解办法是缩短上报周期：
[DEFAULT] # 默认60秒，压测时可设为30，生产环境不建议低于45 resource_tracker_interval = 45
但更关键的是别依赖“实时空闲率”做调度决策。真正可靠的过滤器是RamFilter和DiskFilter，它们读取的是Placement持久化的资源视图，而非libvirt瞬时统计。如果你发现调度异常，优先检查openstack resource provider list输出是否与virsh nodeinfo结果一致，而不是盯着top看CPU。
