物理机异常重启直接影响其上所有云主机。每次重启都应定位根因，避免反复发生。
本文覆盖最常见的几类根因和对应的排查方法。
判断：正常重启还是异常重启？
正常重启的特征是系统日志中有明确的 shutdown/reboot 指令记录，或在计划维护窗口内。
异常重启的典型信号：
/var/crash/ | |
ipmitool sel list | |
快速确认命令：
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.log
cp /var/log/messages /tmp/diag-$(date +%Y%m%d-%H%M)/messages.log
ipmitool sel list > /tmp/diag-$(date +%Y%m%d-%H%M)/ipmi-sel.log
cp -r /var/crash/ /tmp/diag-$(date +%Y%m%d-%H%M)/crash-files/ 2>/dev/null
日志应尽早保存——后续系统运行可能覆盖关键信息。
根因排查：硬件 → 内核 → 软件
一、硬件错误
硬件故障是异常重启最常见的原因，好在定位路径明确，日志通常能指向具体部件。
内存（EDAC/MCE）
dmesg | 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。更换对应内存后恢复。
处理原则：
· CE（Correctable Error）→ 观察频率，频率上升则更换
· UE（Uncorrectable Error）→ 立即更换
· 定位物理槽位：dmidecode -t memory 对照 EDAC 输出
CPU（MCE / Cache）
mcelog --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 持续报错则需要更换。
电源 / PSU
ipmitool sel list | grep -i "power\|PSU\|voltage"
典型信号：
· IPMI SEL 出现 "Power Supply Failure" 或 "Voltage Threshold Exceeded"
· 瞬间断电后自动恢复——此时操作系统日志完全空白，仅 BMC 日志有掉电记录
· 双电源冗余环境中，单 PSU 故障不会立即停机，但负载突变可能触发另一个 PSU 过载
温度过高
ipmitool sdr list | grep -i "temp"
BMC 检测到 CPU 或进风口温度超过临界阈值时，会触发保护性关机。IPMI SEL 中可见 "Temperature Upper Critical"。常见原因：机房制冷故障、风扇异常、进风口阻塞。
BMC Watchdog
ipmitool sel list | grep -i "watchdog"
系统 hang 住超过 BMC watchdog 超时时间后，BMC 触发强制重启。Watchdog 本身不是根因——系统为何 hang 住才是需要进一步排查的问题。但 watchdog 记录的时间戳可帮助确认事件时间线。
PCIe 设备
dmesg | grep -i "PCIe\|AER\|DPC"
PCIe AER（Advanced Error Reporting）或 DPC（Downstream 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 挂载参数增加 timeo=600,retrans=2，降低短暂抖动导致的硬挂起
· 配置存储 IO 延迟告警
· 高峰期控制并发存储操作数
四、组件异常（libvirtd）
libvirtd 长期运行后可能出现服务不响应，但进程状态显示正常。
特征：virsh list 卡住或返回错误，systemctl status libvirtd 显示 active 但不响应请求。
处理方式：
· 短期：业务低峰期定期重启 libvirtd
· 长期：升级 libvirt 至修复版本
重启后环境完整性检查
自查清单
☐ 业务已恢复正常（云主机运行、集群状态正常） ☐ 已保存全套日志（messages / dmesg / journal / ipmi sel / crash） ☐ 硬件层已排除：ipmi sel 无新错误，EDAC/MCE 无告警 ☐ 内核层已排除：/var/crash/ 无新 vmcore，messages 无 panic 记录 ☐ 软件层已排除：libvirtd / kvmagent 正常运行，无 IO 过载信号 ☐ 重启后环境完整：网络 / 存储 / 虚拟化 / 云主机均正常 ☐ 重复重启场景已记录历史重启日志供对比
联系技术支持的时机
每次异常重启，都值得追到根因。 日志尽早保存，排查顺序从硬件到内核再到软件，避免同一问题反复发生。
