OpenStack虚拟机重启后无法连接，绝大多数情况下是网络配置或服务状态异常导致的，按“控制台→网络→安全组→服务→底层”顺序排查，多数问题能在十分钟内定位。
openstack云主机重启后网络不通，先按这套顺序排查
虚拟机重启后失联,第一反应别急着重建实例，很多问题其实只是重启过程中某个环节没跟上，直接重建反而丢失数据，业内专家指出，重启后无法连接的问题中，相当一部分是网络层配置未持久化或DHCP租约未更新引起的，并非系统崩溃。
第一步：先走控制台确认系统活着
用OpenStack Horizon或nova get-vnc-console拿到VNC控制台，看虚拟机是否正常启动到登录界面，这一步能快速区分是系统层面故障还是网络层面故障。
- 能看到登录界面：系统正常，问题在网络层，继续往下查
- 黑屏或卡在grub：系统启动异常，重点看后端计算节点的virsh console输出
- 卡在“Starting network...”类似字样：说明网络服务启动时就出了问题
控制台能登录的话,先看IP地址还在不在，重启后IP丢失是常见故障，原因是网卡配置文件里写的不是DHCP，而是固定IP，但虚拟机的唯一标识（如netplan/mac地址映射）在重建或迁移后变了。
第二步：判断是ping不通还是ssh连不上
很多人把这两个混为一谈,排查方向完全不同。
- ping不通：三层网络问题，查路由、安全组、DHCP
- ping得通但ssh超时：二层或应用层问题，查ssh服务、防火墙、iptables规则
建议先ping网关，在虚拟机控制台里ping它的网关IP，如果网关通但外网不通，大概率是路由表丢失；如果网关也不通，问题在虚拟网络层面，比如OVS流表异常或neutron-agent失联。
openstack虚拟机ping不通，但控制台能进的情况
这种场景相当常见,系统活着，但网络对外不可达，多数情况下和安全组或者DHCP租约有关。
检查安全组规则是否“丢”了
重启后安全组没丢,但规则可能没生效，特别是用旧镜像创建的实例，云平台组件版本有差异时，安全组规则的iptables链可能在重启过程中没重新加载。
在计算节点上执行：
iptables -L -n | grep <实例IP>
看看有没有对应的ACCEPT规则,如果没有，重启neutron-openvswitch-agent服务：
systemctl restart neutron-openvswitch-agent
DHCP租约过期导致IP分配异常
这个坑很隐蔽,虚拟机重启速度快，DHCP租约还没到期，按理说会续租同一个IP，但如果网络命名空间里的dnsmasq进程挂了，虚拟机就拿不到IP或者拿到一个不冲突但无法路由的IP。
排查方法：在网络节点上看dnsmasq进程是否正常，重启neutron-dhcp-agent再观察。
检查网关ARP表
计算节点上执行ip neigh命令，看虚拟机IP的MAC地址是否还在ARP表里，重启后MAC地址没变，但如果网关设备（比如路由器命名空间）里的ARP条目失效，数据包就发不出去。
OpenStack虚拟机SSH连接不上，如何定位服务端问题
网络通了但连不上22端口,这种情况常见于云主机重启后sshd没起来，或者host key冲突。
sshd服务是否正常启动
控制台登录后执行：
systemctl status sshd
如果是disabled状态,说明云镜像里的ssh服务默认没设置为开机自启。多数云镜像会通过cloud-init来配置ssh，如果cloud-init执行失败，sshd可能不会被拉起。
SSH host key冲突
重启后,特别是从快照恢复的虚拟机，可能被OpenStack认为是一个新实例，导致计算节点上的libvirt配置指向了不同的SSH host key路径，这个情况少见，但碰到了会非常困惑，因为控制台一切正常，网络也通，就是ssh握手失败。
解决方式：删除虚拟机内的/etc/ssh/sshhost 文件，重启sshd重新生成。
底层云平台视角：虚拟化层与网络层的协同排查
如果单台虚拟机有问题,上面几步基本够用，但如果是批量虚拟机重启后都无法连接，就得看底层云平台组件了。
nova-compute与neutron服务状态
在计算节点上执行：
openstack service list openstack network agent list
重点看nova-compute、neutron-openvswitch-agent是否处于up状态。agent掉线是批量网络故障的常见原因，特别是OpenStack版本跨度较大的升级场景中。
统一排查顺序表
| 排查对象 | 常见错误信号 | 操作入口 | 优先级 |
|---|---|---|---|
| 虚拟机系统 | 无法进入登录界面 | VNC控制台 | 最高 |
| IP配置 | ifconfig无IP或网段错误 | 虚拟机内部 | 高 |
| 网关连通性 | ping网关超时 | 虚拟机内部 | 高 |
| 安全组规则 | iptables无对应条目 | 计算节点 | 中 |
| DHCP服务 | dnsmasq进程不存在 | 网络节点 | 中 |
| 云平台agent | neutron-agent显示down | 控制节点 | 低（批量故障时优先） |
计算节点资源耗尽导致的重启异常
有一种特殊情况：虚拟机“重启后”其实没有完成真正重启，而是卡在QEMU层面的某个状态，检查计算节点上是否有足够的CPU和内存余量，用virsh list --all看看实例的实际状态。
如何预防OpenStack虚拟机重启后失联
排查完问题,还得防止再犯，以下几条经验值得沉淀到运维规范里。
模板层面：确保cloud-init完整执行
制作镜像时务必确认cloud-init能完整跑完，特别是network、ssh、hostname这几个模块。多数重启后网络不通的问题，根源其实是镜像里cloud-init配置不完整，首次启动能联网是因为镜像创建时手动配置过，重启后配置丢失。
应用层面：关键服务设置开机自启
在镜像模板里统一配置：
systemctl enable sshd systemctl enable network
同时写一个网络健康检查脚本,开机后延迟30秒检测网关连通性，不通则重启网络服务。
运维层面：建立重启后验证清单
- 重启前记录虚拟机的IP、所在计算节点、关联的安全组
- 批量重启时逐个确认,别用nova reboot --all这种高危操作
- 重启后优先看nova instance-action日志，判断是否完成完整启动流程
虚拟化环境下的常见误区
以下误区在排查过程中容易走弯路,提前规避能节省不少时间。
重启后IP变了就认为是IP耗尽，OpenStack的DHCP机制默认会尽量分配原IP，如果变了，大概率是端口绑定关系被重置了，查nova和neutron的端口映射关系，别急着调整DHCP池。
盲目重建实例，重建虽然能解决大部分问题，但会丢失系统盘数据，如果虚拟机里有数据库或未同步的配置文件，重建是不可逆的，先把磁盘做快照再折腾。
只在虚拟机内部排查，OpenStack是个分布式系统，虚拟机的网络路径经过了虚拟网桥、OVS流表、命名空间路由、物理网卡，任何一环出问题都会导致网络不通，但虚拟机内部看不到这些链路，学会从计算节点和网络节点两个视角交叉验证。
openstack虚拟机网络故障排查中，如何区分平台问题与系统问题
这是最终判断归属的关键能力。
创建一台测试实例做对照
在同一网络、同一计算节点上新建一台测试虚拟机，如果测试实例也网络不通，说明平台层有问题；如果测试实例正常，说明原来那台虚拟机自身有问题，这个对照实验的定位效率极高。
查看虚拟机的metadata服务
虚拟机启动时从169.254.169.254获取metadata，如果这个服务不可达，会影响cloud-init执行，进而导致网络配置异常，在虚拟机内执行：
curl http://169.254.169.254/latest/meta-data/
返回正常说明链路没问题,返回超时则看neutron-metadata-agent是否正常。
常见问题解答
Q：openstack虚拟机重启后无法连接，怎么快速恢复业务？
A：先通过VNC控制台登录，确认系统正常后，手动执行dhclient或重启网络服务，大概率能恢复，如果网络服务起不来，检查网卡配置文件里的MAC地址是否和云平台端口绑定信息一致，恢复业务优先于排查根因，先把服务拉起来再定位。
Q：虚拟机重启后IP变了，怎么处理？
A：查看neutron端口列表，确认原端口是否仍然存在，如果端口没了，说明是虚拟机的网卡在重启过程中被重新创建了，建议在镜像模板的网卡配置里使用DHCP而非固定IP，同时启用端口级别的allowed-address-pairs来绑定浮动IP，如果业务必须依赖固定IP，改用neutron的端口固定IP功能，在创建实例时显式指定。
Q：nova reboot之后，主机连不上原来挂载的块存储卷了。
A：这是块存储设备名漂移导致的，重启后系统盘和云硬盘的设备名顺序可能变化，比如原先是/dev/vdb变成了/dev/vdc，在/etc/fstab里不要使用设备名，改用UUID或LABEL来挂载，同时检查cinder的volume attach状态，确认卷没有被detach，设备名问题在包含多块卷的实例上尤其常见。