实例 ACTIVE、IP 已分配、就是连不上排查到底才发现Glance 里那个“镜像”根本不是镜像是一个 273 字节的 HTML 文件一、部署概述项目值环境10.10.10.160 单机CentOS 7.9 Train OVN现象入口实例 ACTIVE 但 SSH/ping 全不通最终根因Glance 镜像实为 HTTP 302 重定向页面上篇回顾四创建第一台云主机——按流程创建了实例但遇到“ACTIVE 却连不上”的诡异现象。本篇是这次排查的完整实录也是本系列我认为最有价值的一篇它示范了如何在多层干扰下坚持用证据说话。二、现象完整记录openstack server create返回ACTIVE实例分配到了 IP10.0.0.127SSH 不通、浮动 IP ping 不通console.log里没有内核引导输出只有 cloud-init 的 guest 元数据virsh dominfo 实例 | grep CPU time显示几分钟只消耗1.6 秒 CPU正常引导要几十秒第一反应是查网络——安全组、路由、OVN agent 全部正常。排除网络。第二反应是无 KVM 环境引导慢坑 5等了十分钟依然如故。排除“只是慢”。此时证据链指向实例的“种子”有问题即镜像。三、定位过程3.1 从实例磁盘倒查实例磁盘的 base 文件在计算节点上bashfile /var/lib/nova/instances/_base/base_id输出赫然是HTML document实例磁盘的 base 竟然是一个 HTML 文件——问题不在网络在镜像。实例“启动”的是一个网页。3.2 回溯 Glance 存储层bashhead -c 200 /var/lib/glance/images/id!DOCTYPE HTML PUBLIC -//IETF//HTM//DTD HTML 2.0//ENtitle302 Found/title ...根因水落石出Packstack 用CONFIG_PROVISION_IMAGE_URLhttps://download.cirros-cloud.net/0.3.5/...下载镜像该 URL 返回302 重定向指向 GitHub。下载器没有跟随重定向就把 302 响应页当镜像注册进了 Glance。3.3 识别该问题的第一线索背下来bashopenstack image show cirros -c size -c disk_format -c status -f value# size 273 ← 中招的铁证ls -lh /var/lib/glance/images/ # 文件只有 273 字节file /var/lib/glance/images/id # HTML document**这个假镜像最狡猾的地方status 依然是 active、disk_format 看起来也正常openstack image list里它堂而皇之地躺着。唯一露馅的是 size273。**这就是坑 2 的完整形态——以后任何时候怀疑镜像第一件事就是看 size。四、修复实测通过bash# 1) 用能跟随重定向的方式下载真实镜像-L 是关键内网无外网则从镜像站取curl -sL -o /root/cirros-0.3.5-x86_64-disk.img \https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.imgqemu-img info /root/cirros-0.3.5-x86_64-disk.img# qemu-img info 输出确认# file format: qcow2# virtual size: 39M# disk size: 13M ← 这才是正常镜像# 2) 替换 Glance 镜像# ★ 注意openstack image set 不支持 --file坑 6走删旧建新openstack image delete cirrosopenstack image create cirros \--file /root/cirros-0.3.5-x86_64-disk.img \--disk-format qcow2 --container-format bare --public# 3) 重建实例验证openstack server create --flavor m1.tiny --image cirros \--network private test-vm2openstack console log show test-vm2 | head修复后 console.log 出现完整内核引导输出CirrOS 登录横幅实例可正常登录。前后对比的判据就是第四篇的“真活三连”。预防措施把应答文件的CONFIG_PROVISION_IMAGE_URL改成内网不会重定向的地址或部署后立即验 size。五、通用排查起手式沉淀这次排查验证过的一套起手命令任何 OpenStack 故障都从它开始bash# ① 环境变量是否加载坑 4/系列坑CLI 报 401 十有八九是没 sourcesource /root/keystonerc_admin# ② 服务是否活着注意坑 3httpd 承载的服务 unknown 属正常systemctl status httpd mariadb rabbitmq-server memcached \openstack-nova-api openstack-nova-compute neutron-server \openstack-glance-api openstack-cinder-volume# ③ 端口是否在听netstat -lntp | grep -E :(80|5000|8774|8778|9292|9696|8776)\b# ④ 时间是否同步Token / MQ 的头号杀手chronyc sources# ⑤ 日志三连tail -f /var/log/keystone/keystone.logtail -f /var/log/nova/nova-compute.logtail -f /var/log/neutron/server.log排查总原则先看服务在不在 → 再看日志报什么 → 再查配置/时间/权限 → 最后查依赖DB / MQ / Keystone服务名陷阱再强调一次CentOS 下计算节点的服务单元是openstack-nova-compute而nova-api / glance-api / keystone / placement-api由httpdmod_wsgi承载systemctl is-active openstack-nova-api返回unknown此时应查httpd。六、分组件常见故障速查表组件典型现象排查入口常见原因Keystonetoken issue 401、Dashboard 登录失败systemctl status httpd、keystone.logMariaDB 密码错查 keystone.conf 的 database 连接时钟不同步配 chrony未 source / AUTH_URL 错Glance上传报 Image service not available、镜像卡 queuedglance-api 服务与日志服务挂了★size273 即 302 坑Nova实例创建失败、一直 building、ACTIVE 假活nova-compute.log、compute service list镜像坏、调度资源不足、compute 服务 downNeutron网络创建失败、实例拿不到 IPserver.log、network agent listOVN agent 不 Alive、physical-network 映射错Cinder卷创建/挂载失败cinder-volume 日志后端存储未就绪、卷类型不存在Dashboard502/登录循环httpd 与 horizon 日志session 后端memcached异常七、「ACTIVE 但连不上」完整决策树把本次排查经验整理成一棵可查表的决策树下次遇到直接对号入座text实例 ACTIVE 但 SSH/ping 不通│├─ ① openstack image show -c size → 几百字节│ └─ 是 → 302 镜像坑第四节修复│├─ ② openstack console log show → 有内核引导输出│ ├─ 没有 → 实例没引导查镜像 size / 无 KVM 引导慢多等 3 分钟│ └─ 有内核输出 → 实例活着问题在网络层 ↓│├─ ③ 安全组放行 icmp/22 了吗│ └─ 没放 → 加规则坑 4多数人卡在这里│├─ ④ 浮动 IP 绑了吗router 有外网网关吗│ └─ 没绑/没设 → floating ip create router set --external-gateway│└─ ⑤ 还不通 → network agent list 看 OVN agent└─ AliveFalse → systemctl status ovn-controller决策树的排序原则最容易验、最常见的先查镜像 size 一条命令安全组是最高频翻车点需要登录节点查 virsh 的动作放最后。八、日志关键字速查卡排障时用grep -E ERROR|WARNING 日志快速过滤常见关键字对应日志文件关键字/报错含义nova-compute.logImageNotFound镜像 ID 无效或被删nova-compute.logImageUnacceptable镜像格式/内容被拒★273 字节坑在这露馅nova-scheduler.logNo valid host没有节点满足规格/镜像要求keystone.logUnauthorized/ 401Token 无效没 source / 时钟漂移 / 密码错neutron-server.logPhysical network ... not foundphysical-network 映射名不一致各服务日志AMQP ... connection refusedMQ 连不上rabbitmq 挂了或防火墙各服务日志Connection reset by peer对端服务重启过去看对端日志背下这几个关键词能解决 80% 的入门期报错定位。九、被忽视的一环metadata 链路实例开机后能从 169.254.169.254 拿到主机名/SSH 公钥/网络信息链路是实例 → Neutron 路由器命名空间的 metadata-proxy → nova-api。它坏了的症状很典型实例能引导能登录但 cloud-init 卡住或拿不到 IP。bash# 实例内执行curl -s http://169.254.169.254/latest/meta-data/hostname# 正常返回实例主机名超时则 metadata 链路断了本次事故里 console.log 只有 cloud-init 元数据、没有内核输出与 metadata 故障的表现易混淆——判据是看 cloud-init 输出里有没有报错这也是为什么坚持要看原始 console.log 而不是只看 dashboard 状态。九点五、专题无 KVM 环境的排障心得本系列环境没有 KVM这个“残缺”设定本身产出了不少排障经验判断实例是真在引导还是卡死无 KVM 下尤其实用bash# 取两个时间点的 CPU time差值持续增长 在干活virsh dominfo instance-00000001 | grep CPU time# 等待 30 秒再执行一次CPU time 在涨 console.log 在追加内核日志 正常无 KVM 就是慢cirros 要 1~3 分钟CPU time 不动 console.log 无输出 没引导查镜像本文主角宿主机开启 VT-x 的完整步骤关机虚拟机 → VMware 设置 → 处理器 → 勾选「虚拟化 Intel VT-x/EPT」开机后验证ls /dev/kvm出现设备文件建实例时看openstack hypervisor stats showCPU 信息会变化对比效果cirros 引导从几分钟降到几秒差别是数量级的为什么无 KVM 会慢到这个程度QEMU TCG 是把虚拟机的每条指令用软件翻译执行效率约为硬件虚拟化的 1/10~1/30。内核引导要执行上亿条指令所以分钟级的引导时间是合理的——这个认知直接决定了排障时“等多久才算等够了”的判断标准。另外记录一个实测细节无 KVM 环境下openstack console log show有时报Console log not available——去计算节点直接看/var/lib/nova/instances/UUID/console.log文件更可靠。十、方法总结这次排查教会我的三件事不要相信任何单一状态字段ACTIVE、active、enabled 都只是“账面”行为证据console.log、CPU time、连通性才是真相排除法要沿调用链走网络 → 时间 → 资源 → 数据源镜像每一层用一条命令证伪比漫无目的翻日志高效得多size 是镜像体检的第一指标openstack image show -c size应该写入肌肉记忆核心教训实例 ACTIVE ≠ 真在运行。判断标准永远是console.log 有内核输出 CPU time 在涨 IP 可连通。下篇预告六运维脚本健康检查与巡检——与其等出事再排查不如每天一分钟巡检。两个实测脚本直接抄走。