nova组件虚拟机创建失败怎么办？，虚拟机创建失败如何解决

nova组件虚拟机创建失败，核心排查思路是：先确认边界，再看日志，最后针对性修复绝大多数问题集中在计算节点状态异常、资源不足或镜像配置三类原因上。

nova虚拟机创建失败原因排查思路

遇到nova组件虚拟机创建失败，不要急着反复重试，OpenStack的请求链路较长，从nova-api到scheduler再到compute节点，每个环节都可能成为瓶颈，按我的实战经验，多数情况下故障集中在两个节点：nova-scheduler没有选出合适的主机，或者nova-compute所在的物理机状态不健康。

先输入一行基础命令,确认全局状态是否正常：

openstack compute service list

这条命令的输出结果会直接告诉你每个nova组件服务是否处于up状态，如果某个计算节点的nova-compute显示为down，说明这台机器的心跳上报已经断了,建议立刻登录物理机检查进程存活状态和系统负载。

如果所有服务都是up，再看虚拟机最终被调度到哪台物理机上,以及创建任务卡在了什么阶段：

openstack server show <instance-uuid>

你也可以通过openstack server list --all-projects找到失败实例的UUID，然后去对应的nova-conductor日志里查询此次创建任务的完整生命周期，行业共识认为，这类排查工作最好在控制节点完成，因为nova-api日志和nova-conductor日志集中在控制节点,方便前后对照时间线。

日志分析定位具体故障点

排查nova组件虚拟机创建失败，日志是唯一的可靠依据。在控制节点和计算节点分别查看日志，能覆盖80%以上的故障场景。

控制节点日志

先看调度阶段是否产生了No valid host was found之类的提示：

grep "No valid host" /var/log/nova/nova-scheduler.log

如果调度成功，日志会显示选中了哪台计算节点,此时排查重心转移到对应计算节点的日志上。

再看conductor日志确认创建请求是否顺利下发：

grep "instance-uuid" /var/log/nova/nova-conductor.log

计算节点日志

登录nova-scheduler日志中选中的计算节点，以nova用户身份查看nova-compute日志：

tail -n 100 /var/log/nova/nova-compute.log

重点搜索ERROR、Traceback、Failed这三个关键词，日志中任何一段Traceback都会直接指引你走向具体的错误模块，例如libvirtError意味着Hypervisor层面出了问题，MessagingTimeout

则提示消息队列到计算节点之间的网络有较大延迟,或者计算节点负载过高导致响应超时。

常见报错与对应处理方案

No valid host was found

这条提示代表调度器没有挑出任何一台满足资源要求的计算节点，大多数情况下,导致这个问题的原因有如下几个：

• 计算节点分区剩余空间不足：nova-compute无法完成磁盘配额校验，导致所有可用主机被过滤掉
• 内存或vCPU预留量设置过高：云平台预留资源后，实际上已经没有可分配的资源给新虚拟机
• flavor规格超出节点最大上限：比如flavor要求的内存大于任何一台计算节点的物理内存

针对磁盘空间问题，建议登录计算节点执行df -h查看分区使用率，如果根分区接近满负荷，清理/var/lib/nova/instances目录下已删除虚拟机残留的文件,再重试创建。

资源预留参数一般在大规模生产环境中才会遇到，如果你管理的是小规模集群，优先排查节点本身的状态是否健康。

创建任务卡在BUILD状态长时间无变化

这是竖切用户遇到最多的next阶段问题，表现是虚拟机一直显示BUILD，不变成ERROR，也没有变成ACTIVE,此时需要在计算节点上查询连接libvirt的超时日志：

查看宿主机上nova实例的状态，判断是虚拟机已经创建成功但nova没有把状态回写，还是虚拟机根本没被创建出来，如果virsh list --all能看到该实例，说明虚拟机已经存在，只是nova状态同步失败，重启nova-compute服务可以解决状态不一致的问题：

systemctl restart nova-compute

Failed to connect to libvirt

计算节点上出现这条信息时，说明nova-compute无法与宿主机上的libvirt建立连接，常见原因为libvirtd服务没有正常监听，或qemu-kvm运行环境下libvirt socket文件权限没有被正确配置,操作路径如下：

systemctl status libvirtd
systemctl restart libvirtd

libvirt服务恢复后，再重启nova-compute服务让两者重新建立连接，这类创建失败问题往往不需要修改配置文件，我的经验中大部分案例是物理机在断电或重启后，libvirtd未能正常拉起,导致nova向上层服务上报了不在线的状态。

镜像格式或virt类型不兼容

如果你使用的是qcow2格式镜像，但计算节点配置的virt_type为qemu，且宿主机CPU不支持嵌套虚拟化，虚拟机可能会因为硬件辅助虚拟化无法使用而创建失败，日志中通常会出现

kvm相关的中断错误。

处理方案是确认镜像格式、glance和nova的配置是否一致：

openstack image show <image-id>
grep "virt_type" /etc/nova/nova-compute.conf

如果宿主机本身是物理机，建议将virt_type改为kvm，同时检查宿主机的BIOS是否开启了虚拟化技术，如果宿主机是虚拟机嵌套部署，保持qemu模式,但一定要确认嵌套虚拟化功能是否已开启。

网络资源分配失败

创建虚拟机时，如果日志中出现NeutronError或PortBindingFailed相关字眼，说明网络组件拖累了整个创建流程,这类问题的解决方案需要带入具体场景去判断：

• DHCP地址池耗尽：检查对应网络的CIDR和已分配IP数量
• Open vSwitch代理状态异常：在控制节点执行openstack network agent list查看网络代理是否全部在线
• 安全组规则数超过底层限制：尝试取消安全组绑定，再重新分配防火墙规则

从我的实际运维经验来看，常见的nova虚拟机创建失败原因中，网络组件出错占比不容小觑，很多人先入为主去查nova配置，结果绕了一大圈才发现是DHCP地址池只剩下几个IP地址,浮动IP池已经耗尽。

如何预防nova虚拟机创建失败

从根源上减少此类故障，需要建立一套日常巡检机制。定期执行nova服务的健康检查，能让大多数潜在问题在爆发之前提前暴露。

建议维护一张巡检清单,每一条都是生产环境验证过的实操动作：

• 每天检查openstack compute service list，观察所有计算节点状态是否一致
• 每周检查计算节点根分区和/var/lib/nova/instances目录的磁盘占用率，磁盘写满时nova-compute会直接停车
• 每周检查vCPU、内存超配比例，比值过高时物理机容易出现负载尖峰，导致新建虚拟机初期不稳定
• 每月清理/var/log/nova/目录下超过一定大小的历史日志文件，避免日志撑爆系统盘

另外建议为计算节点配置自动告警机制，当nova-compute服务断开或宿主机负载过高时第一时间通知管理员，多数情况下，如果你在日志里能看到明确的物理资源不足迹象,说明集群的扩容或者资源回收工作已经滞后于业务增长速度。

nova虚拟机创建失败如何从冷迁移环境中恢复

如果你的场景是企业私有化部署的有状态计算节点，且该节点RAID卡或板卡出现过故障需要冷迁移，那么虚拟机创建失败还与底层宿主机的硬件状态强相关,在控制节点执行：

openstack hypervisor show <hypervisor-hostname>

确认该物理机的state字段为up、status字段为enabled，如果该节点曾经故障重启，ideapad上的虚拟设备可能处于残留状态，使用virsh list --all查看后使用virsh undefine清理残留实例,再在nova侧确认对应的虚拟机实例已从数据库中清理干净。

常见内存不足场景的处理顺序

如果新虚拟机创建失败是因为宿主机可用内存低于预留值,可以按以下顺序处理：

1. 查看现有虚拟机内存规格与宿主机总内存的比值，如果大量空运行虚拟机占用内存却无实际业务负载，考虑先关闭闲置虚拟机释放内存
2. 如果需要扩容物理内存，在业务低谷期执行维护窗口操作
3. 尽量让nova-scheduler把新虚拟机调度到内存富余的其他节点，或者临时禁用内存紧俏的节点

nova组件虚拟机创建失败常见问答

Q：nova虚拟机创建失败报错failed to spawn instance，最可能是什么原因？

先看nova-compute日志中最后一段报错，如果日志里没有任何额外信息，只是泛泛的failed to spawn instance，绝大多数情况下与计算节点上nova-compute服务的实际运行环境有关例如磁盘空间不足、libvirt服务异常或者镜像解压目录无权限，先确认计算节点的磁盘分区状态,再确认libvirtd服务是否正常运行。

Q：openstack虚拟机创建卡在spawning状态怎么处理？

spawning状态持续时间超过正常范围时，说明虚拟机在半初始化阶段卡住了，检查控制节点的nova-conductor日志和计算节点的nova-compute日志，如果发现与消息队列相关的时间超时，处理方式是查看RabbitMQ服务节点的连接数是否打满，尽量扩大连接上限或清理异常连接，如果伴随IO错误,则优先排查物理机的存储路径是否损坏。

Q：nova组件虚拟机创建失败的常见原因有哪些？

从生产环境长期运维中总结，nova虚拟机创建失败的常见原因集中在五个方面：计算节点服务异常、物理资源不足、镜像格式不兼容、网络组件故障、消息队列超时，其中资源不足包含CPU、内存、磁盘和IP地址超分，是弹性云平台最经常出现的瓶颈；服务异常和设备故障是私有化部署场景下占比较高的原因,网络与存储的联动故障则是排查成本相对最高的一类。