OpenStack Nova手动部署实战：从零配置计算服务

1. 项目概述：这不是刷机，是给OpenStack装上“心脏”——Nova计算服务的手动部署实战

很多人看到“Nova”第一反应是华为手机新品发布会，点开热搜跳转到nova 11论坛刷机官网，满屏都是“线刷包下载”“解锁BL锁教程”“救砖指南”。但今天我们要聊的Nova，和手机完全无关——它是OpenStack云平台的核心计算服务（Compute Service），相当于整个云计算系统的“心脏”：所有虚拟机的创建、调度、启动、销毁、快照、迁移，全由它指挥调度。所谓“实训项目 六”，不是教你怎么给手机重装系统，而是带你在一台裸金属服务器上，从零开始手动安装、配置、验证Nova服务，不依赖任何自动化脚本或图形界面。这个过程就像亲手组装一台发动机：你要拧紧每一颗螺丝（配置每一行参数），测试每一条油路（验证每个依赖服务），确认每一次点火（启动服务并成功创建实例）。它解决的不是“手机卡顿怎么清缓存”的问题，而是“企业想自建私有云，如何让100台物理服务器像一台超级计算机那样统一调度资源”的底层能力。适合谁？适合正在学习云计算运维、准备考取OpenStack认证（如COA）、或者需要在生产环境做最小化定制部署的工程师。你不需要会写Python，但得能看懂日志报错；不需要精通KVM内核模块，但得知道/etc/nova/nova.conf里[libvirt]节配错了会导致虚拟机根本起不来。我带过的十几期实训班里，90%的学员卡点都在“计算节点libvirt配置”和“服务启动后状态始终为down”这两个环节——这恰恰说明，手动部署的价值不在“快”，而在于把云平台最脆弱、最关键的神经末梢，真正摸透、踩实。

2. 整体设计与思路拆解：为什么坚持“手动”，而不是用DevStack或Ansible？

2.1 手动部署不是复古，是建立系统级直觉的必经之路

有人会问：现在都有DevStack一键部署、Ansible Playbook批量安装，甚至Terraform编排整套环境，为什么实训项目还死磕“手动安装与配置”？答案很实在：自动化工具是高速公路，手动部署是修路的过程图。DevStack跑起来很快，三分钟就能看到Horizon界面，但它把所有服务都塞进一个用户、一个目录、一堆临时端口里，日志混在一起，配置文件被脚本动态生成，你根本分不清Nova API服务和Nova Conductor服务到底监听在哪个端口、用了哪个数据库连接池。而生产环境里，API服务要单独部署在高可用集群上，Conductor要和Scheduler分离部署，数据库连接必须走SSL加密——这些精细化控制，全靠你对nova.conf里每一个section、每一个key-value的理解深度。我去年帮一家金融客户排查Nova服务偶发超时问题，最终定位到是[database]节里max_retries = -1（无限重试）导致连接池耗尽，而这个参数在DevStack默认配置里是隐藏的。手动部署逼你逐行阅读官方文档，理解[DEFAULT]节里的transport_url指向RabbitMQ的哪个vhost，[api_database]和[database]两个数据库配置的区别在哪（前者存API服务元数据，后者存实例生命周期数据），这种肌肉记忆，是任何自动化工具都无法替代的。

2.2 Nova组件的分布式架构决定了配置必须“分而治之”

Nova不是单体服务，它由至少5个独立进程组成，各自承担不同职责：

• nova-api：接收所有REST请求（创建VM、查询列表等），是唯一对外暴露的入口；
• nova-scheduler：根据资源（CPU、内存、磁盘）和策略（随机、过滤+权重）决定把VM调度到哪台计算节点；
• nova-conductor：作为API和数据库之间的“安全代理”，避免API服务直接连DB（防止SQL注入风险）；
• nova-compute：运行在每台物理服务器上，调用libvirt/KVM管理本地虚拟机；
• nova-consoleauth：验证VNC控制台访问权限（虽然现在多用novncproxy）。

手动部署的核心逻辑，就是按角色划分节点：控制节点（Controller Node）部署api/scheduler/conductor/consoleauth，计算节点（Compute Node）只部署compute。这种分离不是为了炫技，而是安全与性能的硬性要求。比如，如果把compute进程也装在控制节点上，一旦某台计算节点的KVM崩溃，整个控制节点的服务可能被拖垮。我在某次实训中故意让学员把所有服务装在同一台机器上，结果当模拟计算节点故障时，scheduler无法获取其他节点状态，整个云平台就“失明”了——这个教训比十页PPT都管用。所以，“手动”的本质，是强制你思考“这个进程该放在哪？它依赖什么？它暴露什么端口？它读写哪些配置？”——这种架构思维，才是云计算工程师的核心竞争力。

2.3 “华为nova 11论坛刷机”热搜的警示：别把云平台当消费电子品

热搜词“华为nova 11论坛刷机官网”之所以高频出现，是因为手机刷机有明确的“成功标准”：屏幕亮了、能进桌面、APP能打开。但Nova部署没有这么简单的验收标准。你systemctl start openstack-nova-api返回active (running)，不代表服务真的健康。它可能连不上数据库（日志里只有Connection refused），可能认证失败（Keystone返回401），可能调度器找不到计算节点（nova service-list显示compute状态为down）。这就是为什么实训项目强调“手动验证”：每启一个服务，必须立刻用curl调API、用openstack server list查资源、用nova-manage db sync校验数据库表结构。我见过太多学员，服务启动后没做任何验证，直接去创建虚拟机，结果卡在“BUILD”状态几个小时，最后发现是计算节点的libvirt-bin服务根本没启动。手机刷机失败顶多变砖，Nova配置错误可能导致整个云平台资源调度紊乱，影响上百台业务虚拟机。所以，“手动”不是低效，而是把“验证”这个动作，刻进每一个部署步骤的DNA里。

3. 核心细节解析与实操要点：计算节点libvirt配置的生死线

3.1 硬件加速检测：不是所有CPU都支持KVM，别让虚拟机跑在QEMU纯模拟上

计算节点能否高效运行虚拟机，第一步不是改配置，而是确认硬件是否“真支持”。很多人忽略这步，直接进入nova.conf编辑，结果虚拟机启动极慢，CPU占用率飙到100%，还以为是配置问题。真相是：你的CPU可能压根没开启Intel VT-x或AMD-V硬件虚拟化支持。

实操验证三步法：

1. BIOS/UEFI层面确认：重启服务器，进BIOS（通常是Del/F2/F12），找到Advanced → CPU Configuration，确认Intel Virtualization Technology或SVM Mode设置为Enabled。这是物理开关，软件无法绕过。
2. Linux内核层面确认：登录系统后执行

   egrep -c '(vmx|svm)' /proc/cpuinfo

   如果返回0，说明内核没检测到硬件加速指令集，即使BIOS开了也没用。此时需检查是否加载了kvm-intel或kvm-amd内核模块：

   lsmod | grep kvm

   若无输出，手动加载：

   modprobe kvm-intel # Intel CPU # 或 modprobe kvm-amd # AMD CPU

   并写入/etc/modules确保开机加载。
3. Libvirt层面确认：执行

   virsh capabilities | grep -A 5 '<domain type='

   正常输出应包含<domain type='kvm'>，如果只有<domain type='qemu'>，说明libvirt默认回退到了纯软件模拟，性能损失可达50%以上。

提示：很多云厂商的“云服务器”默认关闭VT-x，因为要节省成本。如果你在阿里云ECS或腾讯云CVM上部署Nova计算节点，会发现egrep永远返回0——这不是配置问题，是硬件限制。实训必须用物理服务器或支持嵌套虚拟化的云主机（如AWS EC2的i3.metal实例）。

3.2/etc/nova/nova.conf中[libvirt]节的12个关键参数详解

[libvirt]节是Nova计算节点的“灵魂配置”，它告诉nova-compute进程如何与底层KVM交互。配错一行，虚拟机就起不来。下面逐条拆解最易出错的12个参数，附上我的实测经验：

注意：[libvirt]节所有参数都必须在nova-compute服务重启后才生效。不要改完就以为OK，一定要执行sudo systemctl restart openstack-nova-compute && sudo systemctl status openstack-nova-compute确认状态为active (running)，再查/var/log/nova/nova-compute.log末尾是否有INFO nova.virt.libvirt.driver [-] Libvirt initialized字样。

3.3 计算节点服务依赖链：漏掉任何一个，nova-compute就是一具空壳

Nova计算节点不是孤立运行的，它像一棵树，根系深扎在多个基础服务中。手动部署时，必须按严格顺序启动，并确认每个依赖都“活”着：

1. libvirtd服务：这是KVM的守护进程，nova-compute通过它操作虚拟机。启动命令：

   sudo systemctl enable libvirtd && sudo systemctl start libvirtd

   验证：sudo virsh list --all应返回空列表（无VM）或正常VM列表，不能报error: failed to connect to the hypervisor。

2. openstack-nova-compute服务：这是Nova计算节点的主进程。但注意，它启动前必须确保：

   • 数据库（MySQL/PostgreSQL）已创建nova库并授权；
   • 消息队列（RabbitMQ）已创建openstackvhost并授权；
   • Keystone认证服务已注册nova用户、service和endpoint；
   • nova.conf中[database]、[api_database]、[DEFAULT] transport_url、[keystone_authtoken]全部正确。

3. 网络服务（可选但强烈推荐）：如果用Neutron网络，计算节点还需启动neutron-openvswitch-agent或neutron-linuxbridge-agent。但实训项目六通常先用Nova-network（已废弃）或简单桥接，所以重点在br-ex或br-int网桥是否创建成功。

实操心得：我教实训时，会让学员先停掉所有nova服务，然后按libvirtd → rabbitmq-server → mysql → keystone → nova-api → nova-scheduler → nova-conductor → nova-compute顺序逐一启动，并在每步后执行openstack compute service list，观察对应服务状态是否从down变为up。这个过程能让你清晰看到服务间的依赖关系——比如nova-compute一直down，但libvirtd是active，那问题一定出在数据库或消息队列连接上。

4. 实操过程与核心环节实现：从零开始部署Nova控制节点与计算节点

4.1 环境准备：操作系统、网络、基础服务的硬性要求

实训项目六的成功，70%取决于前期环境是否“干净”。我见过太多学员，因为系统没更新、防火墙没关、SELinux没禁用，折腾两天卡在第一步。以下是经过12次实训验证的黄金清单：

操作系统要求：

• 必须用Ubuntu 20.04 LTS或CentOS 8 Stream（OpenStack Yoga版官方支持）。
• 禁止用Ubuntu 22.04（Nova部分组件未适配）或CentOS 7（EOL，安全漏洞多）。
• 最小化安装（Minimal Install），不装GUI，减少干扰进程。

网络配置硬性规则：

• 控制节点和计算节点必须在同一二层网络（如192.168.1.0/24），禁止跨VLAN或NAT。
• 每个节点配置静态IP，禁止DHCP（IP变动会导致RabbitMQ连接中断）。
• /etc/hosts文件必须互相解析：

  # 控制节点的 /etc/hosts 192.168.1.10 controller 192.168.1.20 compute1 # 计算节点的 /etc/hosts 192.168.1.10 controller 192.168.1.20 compute1

  这比DNS更可靠，避免域名解析失败导致服务启动超时。

基础服务预检（每台节点执行）：

# 关闭防火墙（实训环境，生产环境需精细放行） sudo ufw disable # Ubuntu # 或 sudo systemctl stop firewalld && sudo systemctl disable firewalld # CentOS # 禁用SELinux（CentOS） sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config sudo setenforce 0 # 同步时间（NTP） sudo timedatectl set-ntp true sudo systemctl enable chrony && sudo systemctl start chrony # 更新系统 sudo apt update && sudo apt upgrade -y # Ubuntu # 或 sudo dnf update -y # CentOS

注意：timedatectl set-ntp true不是可选项。Nova服务间通信（如scheduler向compute发指令）严重依赖时间同步。我遇到过最诡异的Bug：计算节点时间比控制节点快3分钟，导致Keystone token校验失败，nova service-list显示compute状态为down，日志里全是Invalid token，查了6小时才发现是NTP没开。

4.2 控制节点部署：API、Scheduler、Conductor三位一体

控制节点是Nova的“大脑”，部署顺序必须严格遵循依赖链。以下为Ubuntu 20.04下的完整命令流（CentOS类似，仅包管理器命令不同）：

Step 1：安装Nova服务包

sudo apt install -y nova-api nova-scheduler nova-conductor python3-openstackclient

Step 2：配置数据库连接（以MySQL为例）

# 登录MySQL创建nova数据库 mysql -u root -p > CREATE DATABASE nova_api; > CREATE DATABASE nova; > GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'localhost' IDENTIFIED BY 'NOVA_DBPASS'; > GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS'; > GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY 'NOVA_DBPASS'; > GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS'; > FLUSH PRIVILEGES; > EXIT;

Step 3：配置/etc/nova/nova.conf核心节

[DEFAULT] # 1. 指定消息队列（RabbitMQ） transport_url = rabbit://openstack:RABBIT_PASS@controller # 2. 指定Keystone认证地址 auth_strategy = keystone # 3. 绑定API服务端口 my_ip = 192.168.1.10 [api_database] # 4. API元数据数据库 connection = mysql+pymysql://nova:NOVA_DBPASS@controller/nova_api [database] # 5. 主数据库（实例数据） connection = mysql+pymysql://nova:NOVA_DBPASS@controller/nova [keystone_authtoken] # 6. Keystone认证配置（必须和Keystone中nova用户密码一致） www_authenticate_uri = http://controller:5000/ auth_url = http://controller:5000/ memcached_servers = controller:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = NOVA_PASS [nova_metadata] # 7. 元数据服务（用于cloud-init） metadata_proxy_shared_secret = METADATA_SECRET [oslo_concurrency] # 8. 锁文件路径 lock_path = /var/lib/nova/tmp

Step 4：同步数据库表结构

# 初始化API数据库 sudo nova-manage api_db sync # 初始化主数据库（注意：此命令会创建所有Nova表） sudo nova-manage db sync

Step 5：注册服务与Endpoint

# 创建nova用户（密码NOVA_PASS） openstack user create --domain default --password-prompt nova # 将nova用户加入service项目，赋予admin角色 openstack role add --project service --user nova admin # 创建nova service实体 openstack service create --name nova --description "OpenStack Compute" compute # 创建3个Endpoint（public/internal/admin） openstack endpoint create --region RegionOne compute public http://controller:8774/v2.1 openstack endpoint create --region RegionOne compute internal http://controller:8774/v2.1 openstack endpoint create --region RegionOne compute admin http://controller:8774/v2.1

Step 6：启动并设为开机自启

sudo systemctl enable nova-api nova-scheduler nova-conductor sudo systemctl start nova-api nova-scheduler nova-conductor

验证控制节点：

# 查看服务状态 openstack compute service list # 正常输出应有：nova-scheduler、nova-conductor、nova-consoleauth（若装了）状态为up # 测试API连通性 curl -H "X-Auth-Token: $(openstack token issue -f value -c id)" http://controller:8774/v2.1/os-services # 返回JSON数组即成功

4.3 计算节点部署：专注libvirt与compute服务的精准配置

计算节点部署比控制节点更“专一”，只装nova-compute，但配置更精细。以下是关键步骤：

Step 1：安装计算服务

sudo apt install -y nova-compute

Step 2：备份并编辑/etc/nova/nova.conf

[DEFAULT] # 1. 指向控制节点的消息队列 transport_url = rabbit://openstack:RABBIT_PASS@controller # 2. 指向控制节点的Keystone auth_strategy = keystone # 3. 计算节点自己的IP（必须是实际网卡IP，非127.0.0.1） my_ip = 192.168.1.20 [libvirt] # 4. KVM核心配置（见3.2节详解） virt_type = kvm cpu_mode = host-passthrough ram_allocation_ratio = 1.5 disk_allocation_ratio = 1.0 live_migration_uri = qemu+ssh://nova@%s/system inject_password = false inject_key = false hw_disk_bus = virtio hw_vif_model = virtio [keystone_authtoken] # 5. Keystone认证（密码必须和控制节点一致） www_authenticate_uri = http://controller:5000/ auth_url = http://controller:5000/ memcached_servers = controller:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = NOVA_PASS [oslo_concurrency] # 6. 锁路径 lock_path = /var/lib/nova/tmp

Step 3：启用并启动libvirtd

sudo systemctl enable libvirtd sudo systemctl start libvirtd

Step 4：启动nova-compute

sudo systemctl enable nova-compute sudo systemctl start nova-compute

Step 5：在控制节点验证计算节点注册

# 在控制节点执行 openstack compute service list # 正常输出应有一行： # | 1234 | nova-compute | compute1 | nova | enabled | up | 2023-05-20T08:12:34.000000 | N/A | # 注意：status必须是`up`，state必须是`enabled`

实操心得：如果openstack compute service list里compute状态是down，90%的原因是：

1. 计算节点的my_ip配成了127.0.0.1（必须是真实IP）；
2. 控制节点和计算节点的nova用户密码不一致；
3. RabbitMQ的openstack用户没给compute1节点授权（需在RabbitMQ管理界面检查vhost权限）；
4. 计算节点的libvirtd没启动或启动失败。
   我的排查口诀是：“先看libvirtd，再查nova.conf，最后抓RabbitMQ”。

4.4 终极验证：创建第一台虚拟机，用真实负载检验部署质量

所有配置完成后，必须用真实场景验证。不能只看服务状态，要让它干活：

Step 1：准备基础资源

# 1. 创建网络（使用Provider Network，最简单） openstack network create --share --external --provider-physical-network provider --provider-network-type flat provider # 2. 创建子网 openstack subnet create --network provider --allocation-pool start=192.168.1.100,end=192.168.1.200 --dns-nameserver 8.8.8.8 --gateway 192.168.1.1 --subnet-range 192.168.1.0/24 provider-subnet # 3. 上传Cirros镜像（轻量级测试镜像） wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img openstack image create "cirros" --file cirros-0.6.2-x86_64-disk.img --disk-format qcow2 --container-format bare --public # 4. 创建m1.tiny规格 openstack flavor create --id 1 --ram 64 --disk 1 --vcpus 1 m1.tiny

Step 2：创建虚拟机并监控全过程

# 创建命令（指定网络ID） openstack server create --image cirros --flavor m1.tiny --network provider --key-name mykey test-vm # 实时查看状态 watch -n 1 "openstack server list" # 正常流程：BUILD → ACTIVE（约20-30秒） # 查看详细日志 openstack console log show test-vm # 应看到Cirros启动日志，最后有`login:`提示符

Step 3：压力测试验证稳定性
创建10台VM，检验调度器和计算节点负载：

for i in {1..10}; do openstack server create --image cirros --flavor m1.tiny --network provider "test-vm-$i" & done wait openstack server list | grep -c ACTIVE # 应返回10

注意：如果创建过程中某台VM卡在BUILD超过2分钟，立即查/var/log/nova/nova-scheduler.log（控制节点）和/var/log/nova/nova-compute.log（计算节点）。最常见的原因是计算节点磁盘空间不足（df -h查/var/lib/nova/instances分区），或内存超分配比例过高导致OOM。我建议实训时预留至少20GB空闲磁盘和4GB空闲内存，这是底线。

5. 常见问题与排查技巧实录：那些官方文档不会写的血泪教训

5.1 “nova service-list 显示 down，但 systemctl status 是 active” —— 服务“假活”现象

这是实训中最经典的陷阱。systemctl status openstack-nova-compute显示绿色active (running)，但openstack compute service list里状态却是down。表面看服务起来了，实际它和控制节点“失联”了。原因往往藏在日志深处：

排查路径：

1. 查/var/log/nova/nova-compute.log末尾：

   sudo tail -50 /var/log/nova/nova-compute.log

   如果看到ERROR nova.servicegroup.api [-] Unable to get group members from database或WARNING nova.servicegroup.drivers.db [-] DB returned no data for service group，说明nova-compute无法连接数据库（[database]配置错误或MySQL服务没起来）。

2. 查/var/log/nova/nova-scheduler.log（控制节点）：
   如果看到ERROR nova.scheduler.filter_scheduler [-] No valid host was found，但计算节点明明在线，大概率是计算节点的my_ip配置错误，导致scheduler发心跳包到错误IP。

3. 用tcpdump抓包验证通信：
   在控制节点执行：

   sudo tcpdump -i any port 5672 -w rabbit.pcap # 抓RabbitMQ通信

   在计算节点启动nova-compute后，看是否有SYN包发出。如果没有，说明transport_url里的controller域名解析失败（回到/etc/hosts检查）。

我的独家技巧：写一个nova-health-check.sh脚本，自动检查所有依赖：

#!/bin/bash echo "=== Checking libvirtd ===" sudo systemctl is-active libvirtd echo "=== Checking RabbitMQ connection ===" timeout 5 bash -c "echo -n > /dev/tcp/controller/5672" && echo "OK" || echo "FAIL" echo "=== Checking MySQL connection ===" timeout 5 mysql -h controller -u nova -pNOVA_DBPASS -e "SELECT 1" nova &>/dev/null && echo "OK" || echo "FAIL"

运行它，5秒内定位故障点。

5.2 “虚拟机创建后无法获取IP，ping不通” —— 网络配置的隐形杀手

很多学员成功创建VM，但在控制节点openstack server list看到IP，却ping不通，ssh连不上。这不是Nova问题，而是网络配置的锅。常见于两种场景：

场景1：Provider Network下VM无IP

• 现象：openstack server list显示192.168.1.101，但ping 192.168.1.101超时。
• 原因：计算节点的br-ex网桥没绑定到物理网卡。
• 验证：ip addr show br-ex应有IP，ip link show eth0（物理网卡）状态应为UP，且brctl show显示eth0在br-ex里。
• 修复：

  sudo ovs-vsctl add-port br-ex eth0 # OVS方案 # 或 sudo brctl addif br-ex eth0 # Linux Bridge方案

场景2：VM内ifconfig看不到eth0，只有lo

• 现象：openstack console log show里只有login:，没看到DHCP获取IP的日志。
• 原因：nova.conf中[libvirt] hw_vif_model = virtio配了，但Cirros镜像不带virtio驱动。
• 验证：openstack image show cirros看properties，应有hw_vif_model='virtio'。
• 修复：要么换支持virtio的镜像（如Ubuntu Cloud Image），要么把hw_vif_model改成e1000（性能差，但兼容）。

注意：不要迷信openstack network list显示Status: ACTIVE就代表网络通。必须用ping和ssh实测。我见过最离谱的案例：网络服务状态全绿，但物理交换机ACL规则阻止了ARP广播，导致VM永远拿不到IP——这提醒我们，云平台问题可能出在“云之下”。

5.3 “Live Migration失败，卡在95%” —— SSH密钥与权限的魔鬼细节

Live Migration是Nova高级功能，但实训中常被用来检验部署质量。失败时日志里常出现：
ERROR nova.virt.libvirt.driver [-] Migration operation has aborted: unable to connect to destination libvirt URI

根源分析：

• SSH密钥没配：nova-compute进程以nova用户运行，它需要免密SSH到目标计算节点。但/var/lib/nova/.ssh/id_rsa默认不存在。
• 权限错误：/var/lib/nova/.ssh/目录权限必须是700，id_rsa必须是600，否则libvirt拒绝读取。
• 目标节点没开SSH：sudo systemctl status ssh必须是active。

实操修复四步：

1. 在源计算节点生成密钥：

   sudo -u nova ssh-keygen -t rsa -b 2048 -f /var/lib/nova/.ssh/id_rsa -N ""

2. 将公钥复制到目标计算节点：

   sudo -u nova ssh-copy-id -i /var/lib/nova/.ssh/id_rsa.pub nova@compute2

3. 修正权限：

   sudo chown -R nova:nova /var/lib/nova/.ssh sudo chmod 700 /var/lib/nova/.ssh sudo chmod 600 /var/lib/nova/.ssh/id_rsa

4. 在nova.conf中确认live_migration_uri = qemu+ssh://nova@%s/system（%s会被替换成目标IP）。

血泪教训：有一次Migration失败，查了3小时，最后发现是目标节点的/etc/ssh/sshd_config里PermitRootLogin yes被注释了，而nova用户不是root，SSH连接被拒。解决方案是取消注释并重启sshd。这再次证明，云平台运维的本质，是把Linux底层玩透。

5.4 “创建VM时提示‘No valid host was found’” —— 调度器过滤器的隐性门槛

这个报错看似简单，实则涉及Nova最复杂的调度逻辑。nova-scheduler不是随机选节点，而是按FilterScheduler流程：

1. HostManager获取所有up状态的计算节点；
2. Filters逐个过滤（如RamFilter检查内存，DiskFilter检查磁盘）；
3. Weighers权重打分