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或Ansible2.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硬件虚拟化支持。实操验证三步法BIOS/UEFI层面确认重启服务器进BIOS通常是Del/F2/F12找到Advanced → CPU Configuration确认Intel Virtualization Technology或SVM Mode设置为Enabled。这是物理开关软件无法绕过。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确保开机加载。Libvirt层面确认执行virsh capabilities | grep -A 5 domain type正常输出应包含domain typekvm如果只有domain typeqemu说明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个参数附上我的实测经验参数名推荐值为什么这么配我踩过的坑virt_typekvm强制使用KVM而非QEMU启用硬件加速曾误配为qemu虚拟机启动后立即被kill日志报libvirtError: internal error: process exited while connecting to monitorcpu_modehost-passthrough将宿主机CPU特性完整透传给虚拟机提升性能配custom模式时忘记在cpu_models里加Skylake-Server导致Windows VM蓝屏ram_allocation_ratio1.5内存超分配比例1.5表示物理内存100G可分配150G虚拟内存生产环境曾设为3.0结果OOM Killer干掉nova-compute进程因内存不足无法回收disk_allocation_ratio1.0磁盘不超分配默认避免IO争抢某次为省空间配成2.0结果多台VM同时写磁盘时IO队列爆满iostat -x显示%util持续100%live_migration_uriqemussh://nova%s/systemLive Migration必须用SSH隧道保证迁移过程安全忘记在计算节点创建nova用户并配置免密SSH迁移时卡在Waiting for migration to complete...images_typerbd若后端用Ceph存储必须设为rbd否则镜像无法写入初学者常留默认default导致glance image-create上传的镜像在compute节点找不到images_rbd_poolvmsCeph中存放虚拟机镜像的pool名pool名拼错如写成vm少个snova-compute启动时报rados_connect failedimages_rbd_ceph_conf/etc/ceph/ceph.confCeph配置文件路径必须绝对路径放相对路径ceph.conf服务启动时在/var/lib/nova下找当然找不到inject_passwordfalse禁用密码注入不安全改用cloud-init注入开启后Windows VM启动时卡在Setting up user account...因注入机制冲突inject_keyfalse同上禁用SSH密钥注入同样导致cloud-init无法接管必须关掉hw_disk_busvirtio虚拟磁盘总线类型virtio比ide快3倍以上配ideCentOS7 VM启动时间从15秒涨到45秒hw_vif_modelvirtio虚拟网卡模型virtio网络吞吐是e1000的5倍配e1000VM内iperf3测速只有200Mbps换virtio后达2.1Gbps注意[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计算节点不是孤立运行的它像一棵树根系深扎在多个基础服务中。手动部署时必须按严格顺序启动并确认每个依赖都“活”着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。openstack-nova-compute服务这是Nova计算节点的主进程。但注意它启动前必须确保数据库MySQL/PostgreSQL已创建nova库并授权消息队列RabbitMQ已创建openstackvhost并授权Keystone认证服务已注册nova用户、service和endpointnova.conf中[database]、[api_database]、[DEFAULT] transport_url、[keystone_authtoken]全部正确。网络服务可选但强烈推荐如果用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 StreamOpenStack Yoga版官方支持。禁止用Ubuntu 22.04Nova部分组件未适配或CentOS 7EOL安全漏洞多。最小化安装Minimal Install不装GUI减少干扰进程。网络配置硬性规则控制节点和计算节点必须在同一二层网络如192.168.1.0/24禁止跨VLAN或NAT。每个节点配置静态IP禁止DHCPIP变动会导致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 # 禁用SELinuxCentOS sudo sed -i s/SELINUXenforcing/SELINUXdisabled/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-openstackclientStep 2配置数据库连接以MySQL为例# 登录MySQL创建nova数据库 mysql -u root -p CREATE DATABASE nova_api; CREATE DATABASE nova; GRANT ALL PRIVILEGES ON nova_api.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_api.* TO nova% IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost 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_PASScontroller # 2. 指定Keystone认证地址 auth_strategy keystone # 3. 绑定API服务端口 my_ip 192.168.1.10 [api_database] # 4. API元数据数据库 connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api [database] # 5. 主数据库实例数据 connection mysqlpymysql://nova:NOVA_DBPASScontroller/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/tmpStep 4同步数据库表结构# 初始化API数据库 sudo nova-manage api_db sync # 初始化主数据库注意此命令会创建所有Nova表 sudo nova-manage db syncStep 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个Endpointpublic/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.1Step 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-computeStep 2备份并编辑/etc/nova/nova.conf[DEFAULT] # 1. 指向控制节点的消息队列 transport_url rabbit://openstack:RABBIT_PASScontroller # 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 qemussh://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/tmpStep 3启用并启动libvirtdsudo systemctl enable libvirtd sudo systemctl start libvirtdStep 4启动nova-computesudo systemctl enable nova-compute sudo systemctl start nova-computeStep 5在控制节点验证计算节点注册# 在控制节点执行 openstack compute service list # 正常输出应有一行 # | 1234 | nova-compute | compute1 | nova | enabled | up | 2023-05-20T08:12:34.000000 | N/A | # 注意status必须是upstate必须是enabled实操心得如果openstack compute service list里compute状态是down90%的原因是计算节点的my_ip配成了127.0.0.1必须是真实IP控制节点和计算节点的nova用户密码不一致RabbitMQ的openstack用户没给compute1节点授权需在RabbitMQ管理界面检查vhost权限计算节点的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 start192.168.1.100,end192.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.tinyStep 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。表面看服务起来了实际它和控制节点“失联”了。原因往往藏在日志深处排查路径查/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服务没起来。查/var/log/nova/nova-scheduler.log控制节点如果看到ERROR nova.scheduler.filter_scheduler [-] No valid host was found但计算节点明明在线大概率是计算节点的my_ip配置错误导致scheduler发心跳包到错误IP。用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 “虚拟机创建后无法获取IPping不通” —— 网络配置的隐形杀手很多学员成功创建VM但在控制节点openstack server list看到IP却ping不通ssh连不上。这不是Nova问题而是网络配置的锅。常见于两种场景场景1Provider Network下VM无IP现象openstack server list显示192.168.1.101但ping 192.168.1.101超时。原因计算节点的br-ex网桥没绑定到物理网卡。验证ip addr show br-ex应有IPip 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方案场景2VM内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_modelvirtio。修复要么换支持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/目录权限必须是700id_rsa必须是600否则libvirt拒绝读取。目标节点没开SSHsudo systemctl status ssh必须是active。实操修复四步在源计算节点生成密钥sudo -u nova ssh-keygen -t rsa -b 2048 -f /var/lib/nova/.ssh/id_rsa -N 将公钥复制到目标计算节点sudo -u nova ssh-copy-id -i /var/lib/nova/.ssh/id_rsa.pub novacompute2修正权限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在nova.conf中确认live_migration_uri qemussh://nova%s/system%s会被替换成目标IP。血泪教训有一次Migration失败查了3小时最后发现是目标节点的/etc/ssh/sshd_config里PermitRootLogin yes被注释了而nova用户不是rootSSH连接被拒。解决方案是取消注释并重启sshd。这再次证明云平台运维的本质是把Linux底层玩透。5.4 “创建VM时提示‘No valid host was found’” —— 调度器过滤器的隐性门槛这个报错看似简单实则涉及Nova最复杂的调度逻辑。nova-scheduler不是随机选节点而是按FilterScheduler流程HostManager获取所有up状态的计算节点Filters逐个过滤如RamFilter检查内存DiskFilter检查磁盘Weighers权重打分
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或Ansible2.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硬件虚拟化支持。实操验证三步法BIOS/UEFI层面确认重启服务器进BIOS通常是Del/F2/F12找到Advanced → CPU Configuration确认Intel Virtualization Technology或SVM Mode设置为Enabled。这是物理开关软件无法绕过。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确保开机加载。Libvirt层面确认执行virsh capabilities | grep -A 5 domain type正常输出应包含domain typekvm如果只有domain typeqemu说明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个参数附上我的实测经验参数名推荐值为什么这么配我踩过的坑virt_typekvm强制使用KVM而非QEMU启用硬件加速曾误配为qemu虚拟机启动后立即被kill日志报libvirtError: internal error: process exited while connecting to monitorcpu_modehost-passthrough将宿主机CPU特性完整透传给虚拟机提升性能配custom模式时忘记在cpu_models里加Skylake-Server导致Windows VM蓝屏ram_allocation_ratio1.5内存超分配比例1.5表示物理内存100G可分配150G虚拟内存生产环境曾设为3.0结果OOM Killer干掉nova-compute进程因内存不足无法回收disk_allocation_ratio1.0磁盘不超分配默认避免IO争抢某次为省空间配成2.0结果多台VM同时写磁盘时IO队列爆满iostat -x显示%util持续100%live_migration_uriqemussh://nova%s/systemLive Migration必须用SSH隧道保证迁移过程安全忘记在计算节点创建nova用户并配置免密SSH迁移时卡在Waiting for migration to complete...images_typerbd若后端用Ceph存储必须设为rbd否则镜像无法写入初学者常留默认default导致glance image-create上传的镜像在compute节点找不到images_rbd_poolvmsCeph中存放虚拟机镜像的pool名pool名拼错如写成vm少个snova-compute启动时报rados_connect failedimages_rbd_ceph_conf/etc/ceph/ceph.confCeph配置文件路径必须绝对路径放相对路径ceph.conf服务启动时在/var/lib/nova下找当然找不到inject_passwordfalse禁用密码注入不安全改用cloud-init注入开启后Windows VM启动时卡在Setting up user account...因注入机制冲突inject_keyfalse同上禁用SSH密钥注入同样导致cloud-init无法接管必须关掉hw_disk_busvirtio虚拟磁盘总线类型virtio比ide快3倍以上配ideCentOS7 VM启动时间从15秒涨到45秒hw_vif_modelvirtio虚拟网卡模型virtio网络吞吐是e1000的5倍配e1000VM内iperf3测速只有200Mbps换virtio后达2.1Gbps注意[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计算节点不是孤立运行的它像一棵树根系深扎在多个基础服务中。手动部署时必须按严格顺序启动并确认每个依赖都“活”着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。openstack-nova-compute服务这是Nova计算节点的主进程。但注意它启动前必须确保数据库MySQL/PostgreSQL已创建nova库并授权消息队列RabbitMQ已创建openstackvhost并授权Keystone认证服务已注册nova用户、service和endpointnova.conf中[database]、[api_database]、[DEFAULT] transport_url、[keystone_authtoken]全部正确。网络服务可选但强烈推荐如果用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 StreamOpenStack Yoga版官方支持。禁止用Ubuntu 22.04Nova部分组件未适配或CentOS 7EOL安全漏洞多。最小化安装Minimal Install不装GUI减少干扰进程。网络配置硬性规则控制节点和计算节点必须在同一二层网络如192.168.1.0/24禁止跨VLAN或NAT。每个节点配置静态IP禁止DHCPIP变动会导致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 # 禁用SELinuxCentOS sudo sed -i s/SELINUXenforcing/SELINUXdisabled/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-openstackclientStep 2配置数据库连接以MySQL为例# 登录MySQL创建nova数据库 mysql -u root -p CREATE DATABASE nova_api; CREATE DATABASE nova; GRANT ALL PRIVILEGES ON nova_api.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_api.* TO nova% IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost 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_PASScontroller # 2. 指定Keystone认证地址 auth_strategy keystone # 3. 绑定API服务端口 my_ip 192.168.1.10 [api_database] # 4. API元数据数据库 connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api [database] # 5. 主数据库实例数据 connection mysqlpymysql://nova:NOVA_DBPASScontroller/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/tmpStep 4同步数据库表结构# 初始化API数据库 sudo nova-manage api_db sync # 初始化主数据库注意此命令会创建所有Nova表 sudo nova-manage db syncStep 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个Endpointpublic/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.1Step 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-computeStep 2备份并编辑/etc/nova/nova.conf[DEFAULT] # 1. 指向控制节点的消息队列 transport_url rabbit://openstack:RABBIT_PASScontroller # 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 qemussh://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/tmpStep 3启用并启动libvirtdsudo systemctl enable libvirtd sudo systemctl start libvirtdStep 4启动nova-computesudo systemctl enable nova-compute sudo systemctl start nova-computeStep 5在控制节点验证计算节点注册# 在控制节点执行 openstack compute service list # 正常输出应有一行 # | 1234 | nova-compute | compute1 | nova | enabled | up | 2023-05-20T08:12:34.000000 | N/A | # 注意status必须是upstate必须是enabled实操心得如果openstack compute service list里compute状态是down90%的原因是计算节点的my_ip配成了127.0.0.1必须是真实IP控制节点和计算节点的nova用户密码不一致RabbitMQ的openstack用户没给compute1节点授权需在RabbitMQ管理界面检查vhost权限计算节点的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 start192.168.1.100,end192.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.tinyStep 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。表面看服务起来了实际它和控制节点“失联”了。原因往往藏在日志深处排查路径查/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服务没起来。查/var/log/nova/nova-scheduler.log控制节点如果看到ERROR nova.scheduler.filter_scheduler [-] No valid host was found但计算节点明明在线大概率是计算节点的my_ip配置错误导致scheduler发心跳包到错误IP。用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 “虚拟机创建后无法获取IPping不通” —— 网络配置的隐形杀手很多学员成功创建VM但在控制节点openstack server list看到IP却ping不通ssh连不上。这不是Nova问题而是网络配置的锅。常见于两种场景场景1Provider Network下VM无IP现象openstack server list显示192.168.1.101但ping 192.168.1.101超时。原因计算节点的br-ex网桥没绑定到物理网卡。验证ip addr show br-ex应有IPip 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方案场景2VM内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_modelvirtio。修复要么换支持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/目录权限必须是700id_rsa必须是600否则libvirt拒绝读取。目标节点没开SSHsudo systemctl status ssh必须是active。实操修复四步在源计算节点生成密钥sudo -u nova ssh-keygen -t rsa -b 2048 -f /var/lib/nova/.ssh/id_rsa -N 将公钥复制到目标计算节点sudo -u nova ssh-copy-id -i /var/lib/nova/.ssh/id_rsa.pub novacompute2修正权限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在nova.conf中确认live_migration_uri qemussh://nova%s/system%s会被替换成目标IP。血泪教训有一次Migration失败查了3小时最后发现是目标节点的/etc/ssh/sshd_config里PermitRootLogin yes被注释了而nova用户不是rootSSH连接被拒。解决方案是取消注释并重启sshd。这再次证明云平台运维的本质是把Linux底层玩透。5.4 “创建VM时提示‘No valid host was found’” —— 调度器过滤器的隐性门槛这个报错看似简单实则涉及Nova最复杂的调度逻辑。nova-scheduler不是随机选节点而是按FilterScheduler流程HostManager获取所有up状态的计算节点Filters逐个过滤如RamFilter检查内存DiskFilter检查磁盘Weighers权重打分
