故障处理流程

• 首先确定故障的资源ID，并判断故障发生的组件
• 查看对应组件的日志，根据故障资源ID进行搜索，找到相应的ERROR日志
• 如果ERROR日志又将问题指向了其他组件，则根据ERROR日志中的资源ID、时间、req-id等信息，其他组件继续查找问题，直到发现问题根源。
• 如果没有在日志中发现任何ERROR，有可能是网络不通，导致请求无法到达API，此时需要检查和API的连通性
• 如果API中能找到相应请求，但是conductor/scheduler/compute没有找到相应日志，则有可能是MQ发生故障。
• 如果组件长时间没有任何日志刷新，有可能是组件进程挂掉或者处于僵死状态，可以尝试重启服务，或先打开Debug再重启服务。（对线上环境，重启服务操作需要首先报备，经甲方同意后再操作！）

No valid host was found

• 这个问题产生的很大原因有：
• 计算节点的内存不足、CPU资源不够、硬盘空间资源不足造成的；将云主机类型规格调小点，发现就能创建成功。
• 网络配置不正确，造成创建虚拟机的时候获取ip失败；网络不通或防火墙引起。
• openstack-nova-compute服务状态问题。可以尝试重启控制节点的nova相关服务和计算节点的openstack-nova-compute服务；详细检查控制节点和计算节点的nova.conf配置是否有不当配置。
• 这个报错问题的原因很多，具体要查看/var/log/nova下的日志详细分析。重点是nova-compute.log、nova-conductor.log日志

云主机创建失败基础排障

操作步骤

1.查询云主机信息

nova show <uuid>

nova instance-action-list

若看到云主机已经被删除了，可以使用如下命令：

nova show <uuid> --del\eted

查询云主机信息，能看到flavor、vm uuid、vm name等信息

2.获取req-id

备注：需要进入几个控制节点分别查询nova-scheduler.log去查询，因为每个控制节点都有可能

在物理节点上 可以通过这个命令访问虚拟机

ssh -p 10000 secure@10.101.11.27

切换到root权限命令

sudo su -

进入到nova-scheduler.log日志

cd /var/log/nova

使用vim命令可以直接查看压缩文件

vim nova-scheduler.log-20220830.gz

通过寻找/<uuid>，得到其req-id，并记录

3.通过req-id查看错误信息，并分析