OpenStack怎么配置Nova计算节点管理大规模KVM宿主机-LINUX-PHP中文网

Nova计算节点不管理宿主机，仅通过libvirt调用KVM；大规模宿主机调度由控制节点的nova-scheduler与Placement协同完成，计算节点需确保nova-compute稳定注册、资源上报准确及KVM配置正确。

openstack怎么配置nova计算节点管理大规模kvm宿主机

直接说结论：Nova计算节点本身不“管理”宿主机，它只负责在本机上通过libvirt调用KVM启动/停止实例；所谓“管理大规模宿主机”，其实是控制节点上的nova-scheduler + Placement服务协同完成的资源调度，计算节点只需确保自身nova-compute稳定注册、资源上报准确、KVM配置无硬伤。

为什么`nova-compute`注册后总显示down或resource tracker报错

这是大规模部署中最常见的假性故障——表面是计算节点没起来，实际是控制节点无法确认它的资源状态。核心原因有三个：

nova-compute服务虽然运行着，但没成功向Placement API上报资源（比如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。这不是配置错误，而是默认连接池太小。

Amazon ML

Amazon ML是一组由 AWS 提供的机器学习、生成式 AI 和 AI 应用开发服务。

下载

解决方法是在/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。