企业官网建设流程全解析

如果你已经按系列文章把控制节点、网络节点的基础服务都装好了，那计算节点的工作其实就一件核心事：让这台机器能跑虚拟机。在 OpenStack Queens 版本里，承担这个任务的主角就是 Nova，确切的说是 nova-compute 组件。这篇我把整个计算节点的 Nova 安装过程、配置逻辑、验证方法和容易踩的坑一次性说清楚，按我实际部署的顺序来写，你可以照着往下走。

1. 计算节点在整套环境里的角色定位

1.1 先弄清楚 Nova 组件各自的分工

很多人第一次装 Nova 的时候容易懵，因为 Nova 不是一个单一服务，而是一组服务散落在不同节点上。控制节点上通常会有 nova-api、nova-scheduler、nova-conductor、nova-novncproxy，而计算节点上一般只需要跑 nova-compute，外加一个可能在同机部署的 nova-conductor（小规模环境常用单控制节点 + 多计算节点的结构，conductor 也可以放在控制节点）。

我们用一个生活化的场景来理解：如果你把整个 OpenStack 云平台比作一家酒店，控制节点上的 nova-api 就是前台接待，负责接收客人的入住请求；nova-scheduler 是客房调度员，决定把客人安排到哪栋楼的哪间房；nova-conductor 是酒店的后台管理员，帮助各个岗位协调数据、处理复杂事务；而计算节点上的 nova-compute 则是真正打扫房间、开门迎客的服务员——虚拟机实例真正运行在计算节点上，nova-compute 就是那个负责和底层虚拟化（比如 KVM）打交道、把云硬盘挂载进去、把网络接进来的角色。

所以计算节点的安装核心就两个层面：一个是把 Nova 相关的软件包装好，另一个是把 nova.conf 配置文件写好，让它能够和控制节点上的服务正确通信，然后启动服务、完成验证。

1.2 为什么 Queens 版本还需要单独说

OpenStack 版本迭代很快，Queens 是 2018 年发布的一个版本，它处于一个比较有代表性的过渡期：Placement 服务已经独立出来了，但很多操作流程还保留着旧版的习惯。在实际部署 Queens 时，有一个特别容易踩的坑就是 Placement 的配置遗漏。如果在控制节点上忘了配置 Placement 或者配置不正确，计算节点上的 nova-compute 启动会报一堆让人摸不着头脑的 500 错误。所以我会把配置检查作为一个重点反复提醒，因为这是我在实际部署中遇到最多的问题。

另外，Queens 版本默认支持 Python 2 和 Python 3 的过渡，不同的发行版对应的包名也有些区别。我下面的操作以 CentOS 7 + Queens 为基准，这是当时最常见的部署组合，绝大多数镜像源里的 Queens 包在这套环境上都验证过。

2. 环境准备与前置检查

2.1 计算节点的基础环境要求

在正式动手之前，建议先确认几项前置条件，否则后面配置完了才发现基础环境不对，排查起来会很痛苦。

首先是操作系统版本和网络。我的环境全部使用 CentOS 7.6，最小化安装，计算节点的 IP 假设为 192.168.10.12，主机名设置为 compute1。OpenStack 的服务之间大量依赖主机名解析，所以 /etc/hosts 必须提前配好，不然服务之间通信会奇慢无比，甚至直接超时。这一步千万别省。

然后是时间同步。OpenStack 的认证机制用的是 Keystone Token，Token 有有效期，节点之间的时间偏差过大会导致认证失败。我在部署的时候吃过这个亏——控制节点和计算节点的时间差了五分钟，结果 nova-compute 起来以后，执行 openstack server list 一直报 401。先用 chrony 把所有节点的时间同步到同一台服务器，这是老生常谈但必须确认的一件事。

还有 yum 源。这里主要指的是 OpenStack Queens 的 yum 源和扩展源。CentOS 7 自带的源里没有 OpenStack 的包，需要额外安装。我通常用的是社区维护的 Queens 源，安装 release 包以后会自动配置好。要注意的是，尽量选用稳定的镜像源，国内环境有时需要切换镜像，这里不展开，但记住一点：源没问题，安装过程才会顺。

2.2 创建数据库、服务凭证和 API 端点

按官方文档的顺序，计算节点的安装虽然不涉及数据库操作，但控制节点上必须先为 Nova 准备好数据库和 Keystone 里对应的服务凭证。这个步骤必须在控制节点上完成，为后续计算节点使用 API 做准备。我当时实际操作时的流程如下：

首先在控制节点的 MySQL 里创建三个数据库：

CREATE DATABASE nova_api; CREATE DATABASE nova; CREATE DATABASE nova_cell0; GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'localhost' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'localhost' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'%' IDENTIFIED BY '你的密码'; FLUSH PRIVILEGES;

然后用 admin 凭证创建 nova 用户并赋予角色：

openstack user create --domain default --password-prompt nova openstack role add --project service --user nova admin

创建 Nova 服务和三个端点，这里要注意端点 URL 必须和控制节点 IP 对应：

openstack service create --name nova --description "OpenStack Compute" compute openstack endpoint create --region RegionOne compute public http://192.168.10.11:8774/v2.1 openstack endpoint create --region RegionOne compute internal http://192.168.10.11:8774/v2.1 openstack endpoint create --region RegionOne compute admin http://192.168.10.11:8774/v2.1

创建 Placement 服务用户和端点（这一步是 Queens 之后必须的）：

openstack user create --domain default --password-prompt placement openstack role add --project service --user placement admin openstack service create --name placement --description "Placement API" placement openstack endpoint create --region RegionOne placement public http://192.168.10.11:8778 openstack endpoint create --region RegionOne placement internal http://192.168.10.11:8778 openstack endpoint create --region RegionOne placement admin http://192.168.10.11:8778

我之所以把这些控制端的步骤也写出来，是因为很多教程默认你已经在前几篇配好了，但实际排查问题时你会发现，漏掉 placement 端点是高发问题，在这里多提一句能帮你少走一次弯路。

3. 安装 Nova 软件包与配置文件详解

3.1 计算节点上安装的软件包清单

在计算节点 compute1 上，需要安装的软件包相对较少，核心是 openstack-nova-compute，可能还需要安装 openstack-nova-novncproxy（一般装控制节点）和 python2-openstackclient（命令行工具）。我这里的命令是：

yum install -y openstack-nova-compute openstack-utils

如果你的计算节点需要支持虚拟机迁移、SSR 等功能，后面可能还要装额外的包，但基础安装阶段这两个就够。

装完之后先用 openstack-config 命令修改 /etc/nova/nova.conf 的配置，或者直接用 vim 编辑。我更喜欢用 openstack-config，因为它可以避免手误写错 ini 格式导致服务起不来。下面我按配置文件里的几个分段详细说明。

3.2 nova.conf 里那些关键配置的“为什么”

先看 [DEFAULT] 段。这里主要配置传输后端、API 的地址、VNC 相关的选项等。

[DEFAULT] transport_url = rabbit://openstack:你的密码@192.168.10.11:5672/ my_ip = 192.168.10.12 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver enabled_apis = osapi_compute,metadata vnc_enabled = true vnc_server_listen = 0.0.0.0 vnc_server_proxyclient_address = 192.168.10.12 vncproxy_url = http://192.168.10.11:6080/vnc_auto.html

transport_url 指的是 RabbitMQ 消息队列的地址，nova 各个组件通过它来通信。控制节点的 RabbitMQ 安装在 192.168.10.11。这里如果密码里有特殊字符，注意要正确处理，我遇到过一次因为密码里带了 @ 符号导致连接失败的问题。

my_ip 是计算节点自身的管理 IP，这个 IP 会被用于和其他节点通信、向控制节点上报状态。我之前在一台双网卡机器上部署，my_ip 配错了网卡，结果控制节点看到的 compute 主机 IP 不对，VNC 始终连不上，排查了好久。

use_neutron 设为 True 表示使用 Neutron 网络服务，而不是旧的 nova-network。这也是 Queens 版本之后的默认方式，但手动配置时不要漏掉。

firewall_driver 设置为 NoopFirewallDriver 是为了把安全组过滤交给 Neutron 处理，避免 nova-compute 直接操作 iptables 导致安全组规则冲突。在 Queens 版本里，nova-compute 不再直接管安全组规则，如果这里不设置为 Noop，可能出现网络连通但安全组规则不生效的怪问题。

再看 [api]、[keystone_authtoken] 和 [service_user] 段。这些段负责和 Keystone 认证对接：

[api] auth_strategy = keystone [keystone_authtoken] www_authenticate_uri = http://192.168.10.11:5000/ auth_url = http://192.168.10.11:5000/ memcached_servers = 192.168.10.11:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = 你的密码 [service_user] send_service_user_token = true auth_url = http://192.168.10.11:5000/ auth_strategy = keystone auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = 你的密码

有个细节我特别想提醒：在 Queens 版本里，[keystone_authtoken] 段的 www_authenticate_uri 这个参数名是新引入的，老版本叫 auth_uri。如果你复制网上一些旧教程的配置，可能填的还是 auth_uri，虽然 Queens 的代码还兼容，但在高版本里已经被移除，建议一开始就写对。

[service_user] 是 Queens 引入的新配置，它让 nova 组件在调用其他服务（如 Neutron、Placement）时使用服务用户的 token 而不是用户 token，更安全也更可靠。不配这一段，有时也不会立刻报错，但在某些操作（比如创建虚拟机时获取网络信息）会间歇性出错，我当时排查了很久才定位到这个原因。

[vnc] 段的配置负责让用户通过浏览器访问虚拟机控制台。计算节点上要开放 VNC 端口（默认 5900 起），并且要让 vnc_server_proxyclient_address 指向计算节点自己的 IP。如果配错，控制台页面能打开但黑屏，或者连接直接被拒绝。

然后是最关键的 [placement] 段：

[placement] region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://192.168.10.11:5000/v3 username = placement password = 你的密码

在 Queens 里，如果 Placement 配置缺失，nova-compute 会启动失败或在启动时刷出一堆 500 错误。我在第一次部署时就是因为漏了这段，结果 nova-compute 状态一直是 down，查日志才发现是 placement API 返回 500。后来检查才知道是控制节点上 placement 服务本身没配好，而不是计算节点的问题。这种问题跨节点，定位起来很麻烦，所以两个节点上的配置都要仔细。

[libvirt] 段也很重要，它决定 nova-compute 使用什么虚拟化驱动：

[libvirt] virt_type = qemu

这里我特别说明一下：如果你的 CPU 支持硬件虚拟化（Intel VT-x 或 AMD-V），可以把 virt_type 设为 kvm，性能会好很多。但如果你的机器是虚拟机套虚拟机（嵌套虚拟化）或者 CPU 太老，硬开 kvm 会导致创建虚拟机时报“unable to open /dev/kvm”之类的错误。我在测试环境里用的就是 qemu，虽然性能差一些，但稳定。生产环境强烈建议 kvm，并确保 /dev/kvm 存在。另外建议在 [libvirt] 段加一句：

cpu_mode = none

这是为了避免 nova-compute 在启动时尝试获取 CPU 型号信息而失败，尤其是在容器或某些虚拟化环境里，cpu_mode 设置为 none 能跳过 CPU 特性匹配的检查，减少启动失败的概率。

3.3 同步 nova 数据库与 Cell 注册

控制节点上在配置好 nova.conf 后，需要初始化数据库并创建 cell。这一步在控制节点执行，但在计算节点文章里我还是要提一下，因为它跟计算节点能否正常加入系统直接相关。

在控制节点上执行：

su -s /bin/sh -c "nova-manage api_db sync" nova su -s /bin/sh -c "nova-manage db sync" nova su -s /bin/sh -c "nova-manage cell_v2 map_cell0" nova su -s /bin/sh -c "nova-manage cell_v2 create_cell --name cell1 --transport-url rabbit://openstack:你的密码@192.168.10.11:5672/" nova

其中 cell_v2 create_cell 命令只有在没有 cell 的情况下才需要执行，如果之前已经创建过，再次执行会报重复错误。这时可以用 nova-manage cell_v2 list_cells 查看当前已有的 cell。

还有一个容易忽略的步骤是创建 cell 之后要重启控制节点上的 nova 服务，让 nova-scheduler 能感知到新 cell。之前有次我创建完 cell 没重启服务，调度器一直找不到可用的计算节点，折腾了半天才发现是重启的问题。

4. 启动计算节点服务与验证

4.1 启用并启动 nova-compute 服务

计算节点上的服务相对简单。我们只需要启用并启动 nova-compute：

systemctl enable libvirtd.service systemctl start libvirtd.service systemctl enable openstack-nova-compute.service systemctl start openstack-nova-compute.service

为什么要先启用 libvirtd？因为 nova-compute 依赖 libvirt 来管理虚拟机生命周期。如果 libvirtd 没有启动，nova-compute 会反复尝试连接 libvirt，状态会一直起不来。我在全新环境里遇到过 libvirtd 启动失败的问题，通常是因为 /etc/libvirt/libvirtd.conf 里默认监听配置导致权限问题，或者默认的 qemu:///system 连接失败。解决办法通常是把 libvirtd 的 listen 模式改一下，或者确保当前用户有权限访问 /var/run/libvirt/libvirt-sock。

启动之后，用命令查看服务状态：

systemctl status openstack-nova-compute.service

如果一切正常，你会看到 active (running)。接着查看 nova-compute 的日志，确认它没有刷错误信息：

tail -f /var/log/nova/nova-compute.log

日志正常的情况下，你会看到类似 “Starting nova-compute” 和 “Created VLAN bridge” 之类的信息。注意一些 WARNING 级别的消息不一定都是致命的，比如关于 “Policy doesn't exist” 的警告，多半是某个策略文件没找到，后续不影响使用。真正需要关注的是 ERROR 和 CRITICAL。

4.2 在控制节点上确认计算节点是否成功加入

计算节点服务起来了，不代表它就一定被控制节点正确纳管。还需要在控制节点上执行：

openstack compute service list

如果计算节点正常注册，你会看到类似这样的输出：

+----+----------------+---------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+----------------+---------+----------+---------+-------+----------------------------+ | 1 | nova-conductor | controller | nova | enabled | up | 2024-01-01T00:00:00.000000 | | 2 | nova-scheduler | controller | nova | enabled | up | 2024-01-01T00:00:00.000000 | | 3 | nova-compute | compute1 | nova | enabled | up | 2024-01-01T00:00:00.000000 | +----+----------------+---------+----------+---------+-------+----------------------------+

这里最重要的信息就是 nova-compute 这一行的 State 是 up，而且 Host 正确显示为 compute1。如果 State 是 down，多半是网络不通或者计算节点到控制节点的认证失败。另外如果你用 Queens 创建了不止一个 cell，还需要在控制节点上执行：

nova-manage cell_v2 discover_hosts

这个命令是让 nova 扫描并发现新的计算节点。如果在创建 cell 之后加装了新的计算节点，必须手动运行这个扫描，或者配置一个周期任务自动扫描。很多人在 test 环境里加了一台新计算节点，却发现控制节点上始终不显示，就是因为没有重新 discover_hosts。我个人的习惯是每次改完计算节点配置，都顺手跑一次 discover_hosts 并重启一下 nova-scheduler，稳妥。

再验证一下镜像服务是否可用，在控制节点执行：

openstack image list

如果能列出你之前上传的镜像，说明计算节点的 nova-compute 已经从 Glance 拉取到了镜像列表。这一步的问题是，计算节点在使用镜像创建虚拟机时，如果拉取镜像失败，会卡在 BUILD 状态。这个在后面常见问题里我会专门讲。

最后验证一下能否成功创建虚拟机：

openstack server create --flavor m1.tiny --image cirros --nic net-id=你的网络ID test-instance

创建完之后轮询状态：

openstack server list

如果状态变成 ACTIVE，说明整个 Nova 链路是通的。如果一直卡在 BUILD，那就要按我下面整理的排查思路去查了。

5. 核心流程复盘与参数选择逻辑

5.1 计算节点安装全流程速览

整个计算节点的安装流程可以概括成一张自检清单，我在部署时习惯按这个顺序走：

1. 确认时间同步和主机名解析正常
2. 配置好 OpenStack Queens 的 yum 源
3. 安装 openstack-nova-compute 及相关依赖
4. 编辑 /etc/nova/nova.conf，重点检查 [DEFAULT]、[keystone_authtoken]、[placement]、[vnc]、[libvirt] 段
5. 启动 libvirtd，确保虚拟化底层可用
6. 启动 openstack-nova-compute
7. 在控制节点执行 openstack compute service list 确认状态
8. 执行 discover_hosts 注册到对应 cell
9. 创建测试虚拟机验证全链路

每一步看起来都不难，但配置项里任何一个错误都可能导致后一步出现问题。如果不确定某个参数怎么填，可以先去控制节点看已有的 /etc/nova/nova.conf 里对应段的值，保持一致的风格，减少出错概率。

5.2 参数选择中的几个隐藏逻辑

先说 RabbitMQ 的 transport_url。这个 URL 的格式是 rabbit://用户名:密码@主机:端口/，注意在 Queens 中不支持 ha 模式的多个主机配置，那是 Oslo 后续版本才支持的。如果你后续要扩展成多控制节点的高可用环境，transport_url 的写法会变，但 Queens 单节点部署不用考虑那么多。

再说 VNC 的配置逻辑。vnc_enabled 设为 true 表示开启 VNC 功能，vnc_server_listen 设为 0.0.0.0 是让 VNC 服务监听所有网卡接口，vnc_server_proxyclient_address 是计算节点通知控制节点“我的 VNC 地址是这个”，而 vncproxy_url 是用户在浏览器里访问的代理地址。这四者必须配合正确，否则会出现“能打开浏览器窗口但黑屏”或者“完全打不开”两种情况。我遇到过几次黑屏问题，最后定位到是 vnc_server_proxyclient_address 填了控制节点 IP 而不是计算节点 IP，导致代理去连了一个不存在的 VNC 端口。

再说 Placement 段。这里要特别强调 auth_url 的末尾必须带 /v3，因为 Queens 的 Placement 服务依赖 Keystone v3 API。如果漏了版本号，认证请求会落到 v2.0 的路径上，报 404。这种错误很隐蔽，因为日志里出现的报错可能五花八门。

最后说 compute 节点的 [DEFAULT] 里有个 graceful_shutdown_timeout 参数，这个参数的默认值是 60 秒，表示在关闭虚拟机时等待的时间。如果你在关闭计算节点时发现虚拟机迟迟不能正常关机，可以适当调整这个值，但这不是必配项。我一般只在有特殊需求时才改。

6. 常见问题排查与避坑实录

6.1 nova-compute 服务起不来

遇到最多的就是 nova-compute 服务启动后立即退出，或者一直处于 activating 状态。先看日志：

journalctl -u openstack-nova-compute -f tail -100 /var/log/nova/nova-compute.log

常见的报错有以下几类：

第一类是数据库连接失败。报错信息里会出现类似 “OperationalError: (2003, Can't connect to MySQL server on '192.168.10.11')”。这种情况控制节点上的数据库服务可能没起来，或者 nova 用户的权限没给对。检查控制节点的数据库服务状态，并用 mysql 命令手动测试一下远程连接。我发现很多人在创建数据库用户时只加了 localhost 权限，忘了加 % 权限，导致跨节点访问被拒绝。

第二类是 RabbitMQ 连接失败。日志报错是 “pika.exceptions.AMQPConnectionError” 或者 “connection refused”。检查 transport_url 里的密码是否正确、RabbitMQ 服务是否启动。由于 RabbitMQ 的用户密码是由控制节点部署时创建的，计算节点上的配置必须完全一致，多一个空格都不行。

第三类是 Keystone 认证失败。日志报错是 “HttpException: 401 Unauthorized” 或 “AuthorizationFailed”。这种情况八成是 [keystone_authtoken] 里的用户名密码错误，或者域名信息不对。还有小概率是时间不同步导致 token 无效，先执行 date 命令看看两台机器的时间是否一致。

第四类是 Placement API 访问失败。日志报错是 “Placement API server is currently not available” 或 “HTTP 500”。检查控制节点上 placement 服务是否启动，以及 [placement] 段配置的 URL 和密码是否正确。这类问题我最常遇到，尤其是在刚完成控制节点部署、还没重启过服务的状态下。

6.2 控制台（VNC）连接失败

如果虚拟机能够正常创建，但通过浏览器打开控制台时黑屏或连接不上，排查方向主要有三个：

第一，vncproxy_url 是否配置正确。这个地址是用户浏览器访问的地址，必须能通过浏览器直接访问到控制节点的 6080 端口。如果控制节点上有防火墙，要先放行 6080 端口。

第二，计算节点上是否监听 VNC 端口。在计算节点执行：

netstat -tlnp | grep 5900

正常情况下会看到类似 0.0.0.0:5900 的监听，这说明 VNC 服务已经起来了。如果没有监听，多半是 vnc_enabled 没有设为 true。

第三，vnc_server_proxyclient_address 是否正确。这个值必须是计算节点上控制节点能够访问到的 IP。如果填了 127.0.0.1，控制节点上的 novncproxy 就会去连接计算节点的回环地址，自然连不通。

6.3 虚拟机创建一直处于 BUILD 状态

这是另一个高频问题。虚拟机创建不了，首先看控制节点上 nova-scheduler 的日志：

tail -100 /var/log/nova/nova-scheduler.log

如果日志里出现 “No valid host was found”，通常是 nova-compute 上报的资源信息有问题，或者计算节点没有成功注册到 cell 里。先执行 openstack compute service list 确认 nova-compute 是 up 状态，再执行 nova-manage cell_v2 list_cells 确认 cell 配置正确。

如果日志里出现跟“glance”相关的错误，比如 “ImageSchemaNotFound” 或 “Failed to get image”，说明计算节点无法从 Glance 拉取镜像。检查控制节点的 Glance 服务是否正常、计算节点的 /etc/nova/nova.conf 里是否有 [glance] 段，而且 api_servers 配置是否正确。Queens 版本通常默认填 http://控制节点IP:9292。注意我在一些旧教程里看过 [glance] 段遗漏的情况，导致 nova-compute 默认用 localhost 去连 Glance，跨节点必然失败。

还有一种是创建后状态变成 ERROR，日志里报 “No valid host was found because CPU 或 RAM 不足”，这可能是计算节点上资源确实不够，也可能是 nova-compute 上报给 scheduler 的资源数据有残留。可以用 openstack host show 查看计算节点的资源使用情况。如果是资源数据问题，重启计算节点的 nova-compute 服务通常会重新上报资源。

6.4 网络相关问题

虚拟机创建成功后，如果外部网络 ping 不通，先检查安全组规则和 Neutron 的配置。在 Queens 中，nova 已经彻底不再管理网络，所有网络问题都要去 Neutron 侧查。比如在控制节点执行：

openstack network list openstack subnet list

确认网络和子网是否都处于 ACTIVE。然后检查 Neutron 的 DHCP agent 和 L3 agent 是否正常运行。如果虚拟机拿到了正确的 IP，但无法访问外网，很可能是路由或防火墙规则的问题，而不是 Nova 的问题。这一点也提醒我们，搭建环境时不要把所有问题都往 Nova 上想，整个链路里的任何一个环节都可能出问题。

7. 部署过程中的经验小结

7.1 配置文件管理的习惯

我个人的建议是：所有节点的 /etc/nova/nova.conf 改动前，先备份一份原始文件。配置完之后用 openstack-config --get 把关键段的值打印出来核对一遍，这样不容易漏。比如：

openstack-config --get /etc/nova/nova.conf DEFAULT transport_url openstack-config --get /etc/nova/nova.conf placement auth_url

这个命令可以快速检查你配置的值是否正确，比打开文件去用人眼找快得多。另外，建议把每个节点上的 [keystone_authtoken] 段的密码统一管理，可以用一个环境变量文件来存 admin 和 service 用户的密码，避免写配置文件时复制错。

7.2 日志文件的利用方式

Nova 的日志相对规范，基本能通过日志定位到 90% 的问题。我排查问题的顺序是：先看系统服务状态（systemctl），再看对应组件日志（/var/log/nova/），最后再回头看配置。有些时候多个服务日志同时刷错，比如 nova-compute 和 neutron 的日志里都有 ERROR，这时候优先看启动顺序靠前的服务日志，往往能更快找到源头。

计算节点上还有一个容易被忽略的日志是 /var/log/libvirt/libvirtd.log。如果 libvirtd 有问题，很多虚拟机操作会失败，但 Nova 日志里的报错信息不一定直接指向 libvirt。我遇到过 qemu 进程无法启动的问题，最后是看 libvirtd 日志才发现是 cgroup 配置权限问题。

7.3 资源规划心得

计算节点的硬件资源直接影响虚拟机的性能。我在部署测试环境时，虚拟机使用 qemu 模式，性能会打折扣，但胜在兼容性好。如果是生产环境，务必确认 CPU 支持虚拟化，并且把 virt_type 改为 kvm。同时留意磁盘空间，nova 默认的实例存储目录在 /var/lib/nova/instances，如果分区空间不够，虚拟机磁盘创建会失败。当时我遇到过一次实例目录所在分区满了，nova-compute 日志里却只报一个莫名其妙的文件写入错误，排查了很久才找到原因。建议部署时把 /var/lib/nova 挂载在一个独立的、空间足够的分区上。

7.4 关于后续扩展的一点想法

计算节点搭好之后，整个 OpenStack Queens 环境的基本骨架就算完成了。后面再扩展就是添加新计算节点，其实流程完全一样：安装 openstack-nova-compute、配置 nova.conf、启动服务、在控制节点上 discover_hosts。不需要重复做控制节点上的那些数据库、Keystone 操作，这也是 Nova 分布式设计比较好的地方。

如果后面要接 Ceph 作为后端存储，nova.conf 里还要加 [cinder]、[ephemeral_storage_encryption] 等配置；如果要接 SR-IOV 或者 DPDK 这类高性能网络，计算节点的配置会更复杂。这些都是后话了，先把基础的计算节点跑通，理解 Nova 组件之间是怎么协作的，后面的高级功能才有基础。

我在实际操作中最大的体会是：OpenStack 的安装本身并不难，难的是理解每个配置项背后的依赖关系。只要把控制节点和计算节点之间那些认证、消息队列、数据库的连接关系理顺了，后面很多问题都能一眼看出原因。希望这篇计算节点 Nova 安装的拆解能帮你少踩一些我踩过的坑，把环境顺利搭起来。