物理机异常重启直接影响其上所有云主机。每次重启都应定位根因避免反复发生。本文覆盖最常见的几类根因和对应的排查方法。判断正常重启还是异常重启正常重启的特征是系统日志中有明确的 shutdown/reboot 指令记录或在计划维护窗口内。异常重启的典型信号信号说明uptime 明显短于预期近期发生过重启/var/crash/目录有 vmcore 文件内核崩溃ipmitool sel list有硬件错误内存/CPU/电源异常messages 中有 kernel panic / kernel BUG内核 bug所有日志无异常记录可能为电源瞬时中断需查机房和 BMC 记录快速确认命令uptime last reboot | head -3 journalctl --no-pager -b -1 | tail -30 2/dev/null重启后操作恢复业务保存日志物理机重启后先恢复业务——将云主机拉起确认集群状态正常。业务恢复后收集以下日志用于后续排查mkdir -p /tmp/diag-$(date %Y%m%d-%H%M)dmesg -T /tmp/diag-$(date %Y%m%d-%H%M)/dmesg.logcp /var/log/messages /tmp/diag-$(date %Y%m%d-%H%M)/messages.logipmitool sel list /tmp/diag-$(date %Y%m%d-%H%M)/ipmi-sel.logcp -r /var/crash/ /tmp/diag-$(date %Y%m%d-%H%M)/crash-files/ 2/dev/null日志应尽早保存——后续系统运行可能覆盖关键信息。根因排查硬件 → 内核 → 软件一、硬件错误硬件故障是异常重启最常见的原因好在定位路径明确日志通常能指向具体部件。内存EDAC/MCEdmesg | grep -i EDAC\|MCE\|memory error典型输出示例EDAC MC2: 1 CE memory read error on CPU_SrcID#1_MC#0_Chan#2_DIMM#0该输出直接定位到 CPU 插槽、内存通道和 DIMM 槽位对照dmidecode -t memory可确定物理位置。案例一台物理机反复异常重启messages 和 dmesg 无明显异常。通过 crash 工具分析 vmcore发现持续报错的内存 CE 错误精确到 DIMM。更换对应内存后恢复。处理原则· CECorrectable Error→ 观察频率频率上升则更换· UEUncorrectable Error→ 立即更换· 定位物理槽位dmidecode -t memory对照 EDAC 输出CPUMCE / Cachemcelog --client 2/dev/null || cat /var/log/mcelog 2/dev/null关注 Processor context corrupt、Cache error、TLB error 等关键词。CPU 的 L1/L2/L3 Cache ECC 错误或 TLB 错误会触发 MCE严重时导致立即重启。IPMI SEL 中也会出现 CATERR 或 IERR。同一 CPU socket 持续报错则需要更换。电源 / PSUipmitool sel list | grep -i power\|PSU\|voltage典型信号· IPMI SEL 出现 Power Supply Failure 或 Voltage Threshold Exceeded· 瞬间断电后自动恢复——此时操作系统日志完全空白仅 BMC 日志有掉电记录· 双电源冗余环境中单 PSU 故障不会立即停机但负载突变可能触发另一个 PSU 过载温度过高ipmitool sdr list | grep -i tempBMC 检测到 CPU 或进风口温度超过临界阈值时会触发保护性关机。IPMI SEL 中可见 Temperature Upper Critical。常见原因机房制冷故障、风扇异常、进风口阻塞。BMC Watchdogipmitool sel list | grep -i watchdog系统 hang 住超过 BMC watchdog 超时时间后BMC 触发强制重启。Watchdog 本身不是根因——系统为何 hang 住才是需要进一步排查的问题。但 watchdog 记录的时间戳可帮助确认事件时间线。PCIe 设备dmesg | grep -i PCIe\|AER\|DPCPCIe AERAdvanced Error Reporting或 DPCDownstream Port Containment错误会导致对应设备被隔离或系统重启。网卡、HBA 卡、GPU 等 PCIe 设备均为常见故障点。二、内核崩溃/var/crash/目录下有 vmcore 文件时说明为内核崩溃导致的重启。案例4.18 内核物理机异常重启message 和 BMC 日志均无异常记录。但 vmcore-dmesg 明确显示根因qemu-kvm 进程内核路径踩坏内核栈内核自检触发 BUG 宕机syscalls.h:268。最终通过升级内核版本修复。查看 vmcore-dmesg无需 crash 工具cat /var/crash/*/vmcore-dmesg.txt 2/dev/null关键报错模式·BUG: unable to handle kernel NULL pointer— 空指针解引用·BUG: kernel stack overflow— 内核栈溢出·Kernel panic - not syncing— 不可恢复的致命错误处理方式· 已知内核 bug → 升级至修复版本· 未知 bug → 将 vmcore 提供给技术支持通过 crash 工具深度分析三、存储 IO 过载此场景下物理机本身无故障但存储 IO 延迟过高导致系统级软死锁。特征dmesg 中大量 task blocked for more than 120 seconds伴随 NFS/Ceph IO 超时。案例物理机同时向多个 NFS 存储发起大量请求IO 延迟导致进程阻塞libvirtd 异常kvmagent 检测后触发重启恢复。快速确认dmesg | grep -i blocked for more than\|hung_task\|soft lockup预防措施· NFS 挂载参数增加timeo600,retrans2降低短暂抖动导致的硬挂起· 配置存储 IO 延迟告警· 高峰期控制并发存储操作数四、组件异常libvirtdlibvirtd 长期运行后可能出现服务不响应但进程状态显示正常。特征virsh list卡住或返回错误systemctl status libvirtd显示 active 但不响应请求。处理方式· 短期业务低峰期定期重启 libvirtd· 长期升级 libvirt 至修复版本重启后环境完整性检查检查项命令常见问题虚拟化服务systemctl status libvirtd证书过期导致启动失败网络brctl show网桥配置未持久化重启后丢失多路径存储multipath -ll多路径服务异常导致设备映射错乱Cephceph -s混合盘/全闪盘重启后未自动拉起管理服务systemctl status kvmagent进程未自启动云主机平台 UIHA 是否成功触发恢复自查清单☐ 业务已恢复正常云主机运行、集群状态正常☐ 已保存全套日志messages / dmesg / journal / ipmi sel / crash☐ 硬件层已排除ipmi sel 无新错误EDAC/MCE 无告警☐ 内核层已排除/var/crash/ 无新 vmcoremessages 无 panic 记录☐ 软件层已排除libvirtd / kvmagent 正常运行无 IO 过载信号☐ 重启后环境完整网络 / 存储 / 虚拟化 / 云主机均正常☐ 重复重启场景已记录历史重启日志供对比联系技术支持的时机情况处理方式多台物理机同时异常重启可能为其享组件故障存储/网络立即排查并同步联系技术支持单台 24 小时内重复重启超过 2 次收集全套日志联系技术支持分析根因重启后云主机批量无法启动先手动恢复同时联系技术支持排查存储/网络硬件故障确认根据 ipmi sel EDAC/MCE 日志确认故障件联系硬件厂商更换单次重启未复现业务正常保存日志持续观察一周每次异常重启都值得追到根因。日志尽早保存排查顺序从硬件到内核再到软件避免同一问题反复发生。