确定哪个组件损坏¶

OpenStack 的各种组件之间存在着紧密的交互。例如，上传镜像需要 nova-api、glance-api、glance-registry、keystone，以及可能需要 swift-proxy 的交互。因此，有时很难确定问题的确切位置。本节旨在协助解决这个问题。

查看日志¶

首先应该查看与您尝试运行的命令相关的日志文件。例如，如果 openstack server list 失败，请尝试查看 nova 日志文件并再次运行该命令

终端 1

# tail -f /var/log/nova/nova-api.log

终端 2

# openstack server list

在日志文件中查找任何错误或跟踪信息。有关更多信息，请参阅日志记录和监控。

如果错误表明问题出在另一个组件上，请切换到查看该组件的日志文件。例如，如果 nova 无法访问 glance，请查看 glance-api 日志

终端 1

# tail -f /var/log/glance/api.log

终端 2

# openstack server list

不断尝试，直到找到问题的根本原因。

不幸的是，有时错误在日志文件中并不明显。在这种情况下，改变策略，使用不同的命令；也许直接在命令行上运行该服务。例如，如果 glance-api 服务拒绝启动并保持运行，请尝试从命令行启动守护进程

# sudo -u glance -H glance-api

这可能会打印出错误和问题的原因。

注意

由于某些守护进程会将文件写入用户的主目录，如果未指定 -H 标志，则此写入可能会失败，因此在使用 sudo 运行守护进程时需要 -H 标志。

提示

复杂性的示例

有一天早上，一个计算节点无法运行任何实例。日志文件有点模糊，声称某个实例无法启动。这最终是一个误导，因为该实例只是按字母顺序排列的第一个实例，因此它是 nova-compute 将要接触的第一个实例。

进一步的故障排除表明 libvirt 根本没有运行。这更有意义了。如果 libvirt 没有运行，那么就无法通过 KVM 虚拟化任何实例。尝试启动 libvirt 时，它会立即无声地退出。libvirt 日志没有解释原因。

接下来，在命令行上运行 libvirtd 守护进程。最终出现了一条有用的错误消息：它无法连接到 d-bus。听起来很荒谬，但 libvirt，以及 nova-compute，依赖于 d-bus，而 d-bus 已经崩溃。简单地启动 d-bus 使整个链条恢复正常，很快一切都恢复了运行。