ESXi虚拟机突然挂起通常由存储设备无响应、网络磁盘锁或资源耗尽引发，优先检查vSphere客户端中的主机状态与存储健康度，再按顺序排查虚拟机日志和底层物理资源。
虚拟机挂起的第一现场：分清假死与真死
打开vSphere Client，如果虚拟机界面显示“已挂起”但主机正常，先别急着重启，行业内常遇到两种情况：一种是虚拟机操作系统内部卡死，但VMware Tools仍能响应；另一种是虚拟机对外完全失去心跳，连ping都不通，区分这两点能节省大量排查时间。
- 在“监控-任务和事件”里查看最近几分钟是否有存储超时或设备重置记录，页确认ESXi主机本身是“已连接”且“正常”状态。
- 尝试通过VMware Tools向客户机操作系统发送一次“挂起”，看是否能恢复交互。
如果主机状态异常,那问题往往出在底层物理环境，如果主机正常，只是个别虚拟机挂起，需要沿着存储链路往下挖，记住一条行业共识：存储故障导致的虚拟机挂起占全部故障的较大比例，这是所有虚拟化运维人员绕不开的第一道关卡。
第一步排查：ESXi主机与虚拟机日志的配合诊断
挂起发生后,最先打开的是主机上的vmkernel日志（/var/log/vmkernel.log），大部分存储和网络报错都会出现在这里，具体操作方法是通过SSH登录ESXi主机，执行以下命令：
tail -n 200 /var/log/vmkernel.log | grep -i "scsi|reserv|reset"
关注日志里有没有“Device naa.xxx is power on”或“SCSI command timeout”之类的描述，这些关键词基本锁定存储链路问题，同时打开虚拟机的vmware.log日志（位于存储数据存储对应目录下），搜索“unable to access”或“heartbeat loss”。
常用排查命令按顺序执行：
esxcli storage core device list查看所有存储设备状态esxcli storage core path list查看多路径状态是否Activevgrep -d /var/log/vmkernel.log用logwarn或者esxcli命令实时监控报错
如果日志中反复出现磁盘锁冲突,那要考虑到多台ESXi主机同时访问同一个虚拟机磁盘的场景，尤其在共享存储中，某些第三方备份软件触发VSS快照后，会造成SCSI预留冲突，导致多个主机争抢锁，虚拟机自然挂起，这种场景下需要检查是否存在残留的快照任务或异常的备份作业。
第二步排查：存储链路与NFS/iSCSI连接状态
存储侧问题可以细分为三类：存储设备本身故障、网络链路中断、存储协议异常，通过vSphere客户端进入主机-存储-适配器，可以直观看到所有存储适配器状态。
| 组件 | 正常状态 | 异常表现 |
|---|---|---|
| iSCSI适配器 | 已连接，目标可见 | 目标丢失，路径断开 |
| HBA光纤卡 | 链路速率正常 | 卡口警告或速率下降 |
| NFS挂载点 | 已挂载，挂载点可写 | 只读或无响应 |
对于iSCSI环境,登录到ESXi shell后执行esxcli iscsi session list，查看会话是否频繁重连，对于NFS环境，用esxcli storage nfs list确认挂载状态，并检查物理交换机的端口状态，如果发现存储路径从Active变成了Dead，这就是虚拟机挂起的直接原因。
最典型的场景是存储双控制器负载失衡，当一台控制器重启或固件升级时，路径切换不及时，虚拟机IO在短时间内全部超时，操作系统内部触发I/O错误，最终进入挂起状态，如果需要更换存储控制器，一定要提前维护窗口，先迁移虚拟机再做底层操作。
第三步排查：内存、CPU与资源锁被低估的根源
存储排查无果后,再回头看ESXi主机的资源层面，虽然硬件资源耗尽很少直接导致虚拟机“挂起”，但会出现一种特殊状态：虚拟机进程还在，但CPU调度长期得不到时间片，这种情况在内存超分配严重的主机上偶发出现。
进入主机-监控-性能页面：
- 查看CPU ready值，如果超过20%，说明调度等待严重
- 查看内存swap使用率,大量swap说明物理内存不足
- 查看磁盘延迟,超过50ms就需要警惕
esxtop是深度排查利器，按c键查看CPU，按m键查看内存，按d键查看磁盘，以CPU准备时间为例，如果某个虚拟机CPU的%RDY值持续高于15%，就说明它频繁申请物理CPU但得不到满足，这个状态不会体现为停机，但虚拟机内部应用会表现为无响应，主观感受上就是“挂起”。
内存方面要关注MCTLSZ（内存压缩），如果压缩量持续增长，说明内存压力极大，在极端情况下，ESXi会启动内存回收机制，将虚拟机内存页回收，虚拟机会进入卡顿甚至短暂挂起，建议给关键虚拟机预留内存，或者开启内存热添加。
第四步排查：虚拟机内部层面操作系统和驱动的盲区
一旦排除了ESXi主机、存储和网络层面的问题，就需要进入虚拟机操作系统内部查看，操作方式需要借助vSphere的“控制台”功能，虽然虚拟机看起来挂起，但控制台可能仍然响应，此时可以按Ctrl+Alt+Del尝试唤醒Windows系统，或使用SSH登录Linux虚拟机。
在Windows虚拟机中：
- 查看系统日志中是否存在“延迟写失败”或“Disk Timeout”的警告
- 检查磁盘驱动版本,某些老版本半虚拟化驱动与新版ESXi不兼容
- 检查虚拟机内存是否已满,如果系统内存耗尽会导致内核死锁
在Linux虚拟机中：
- 执行
dmesg | grep -i error查看内核报错 - 执行
vmstat 1 5查看进程阻塞状态 - 检查/etc/fstab中是否有挂载参数错误导致IO卡死
比较常见的问题出在虚拟机安装的vmtools版本与ESXi主机版本差距过大,旧版vmtools在ESXi 8.x环境下可能失去部分心跳功能，让主机误判客户机无响应，进而触发HA重启或挂起，更新vmtools是这类问题的基础解法。
应急恢复操作：强制重启无损吗
如果虚拟机彻底无响应,且确认不是临时IO抖动，只能在vSphere客户端中执行“强制关闭电源”再重新开机，这虽然简单，但要评估数据安全风险。
- 如果虚拟机上运行的是数据库,强制断电可能导致日志文件损坏
- 如果存在未落盘的缓存数据,会直接丢失
- 如果虚拟机有快照,强制重启可能引发快照合并失败
建议在应急恢复前,先对虚拟机的vmdk磁盘做一次快照（如果存储空间允许），快照操作本身是写入元数据，不涉及大规模IO，能提供一个快速回退点，但要注意快照文件会持续增长，恢复后必须及时删除。
另一种恢复方式是挂起-恢复操作：先执行“挂起”，等待30秒再点“恢复”，这个操作会触发虚拟机内存状态的无损保存和恢复，部分由临时IO阻塞导致的挂起状态能被清除，比强制重启温和得多。
预防策略：让挂起事件不再复发
挂起事件的根因解决后,需要从架构层面做预防，行业专家指出，多路径冗余和资源隔离是虚拟化稳定性的基石，缺失这两点，挂起就是家常便饭。
- 为每台ESXi主机配置至少两条独立存储路径,并开启路径策略为“最近使用”或“固定”
- 在主机NIC Teaming中配置独立的存储网络vSwitch，避免与业务流量抢带宽
- 为数据库等高负载虚拟机设置CPU和内存预留,防止资源争抢
- 定期检查快照数量,单个虚拟机快照超过3个会显著降低IO性能
维护一个固定资产管理台账,记录每台ESXi主机、存储设备、交换机的固件版本，虚拟化环境中的怪异挂起问题，大部分与固件版本不一致有关，每年至少做一次固件统一升级，能消除大量潜在故障点。
最后要注意的是监控报警阈值,在vCenter中设置虚拟机的CPUready和磁盘延迟告警，不再依赖用户发现问题，当磁盘延迟持续超过100ms时，及时发送告警，这样在虚拟机挂起之前，就能提前介入处理。
常见疑问解答
ESXi虚拟机挂起和死机有什么区别
死机通常指虚拟机操作系统崩溃,屏幕蓝屏或黑屏，客户机系统完全停止响应，挂起则可能只是IO阻塞或调度异常，虚拟机系统的网络连接中断，但控制台能打开，内存中的进程状态仍然保留，通过VMware Tools的ping测试和vSphere控制台输入，可以快速区分两者。
强制关机后虚拟机无法启动怎么办
强制关机后如果虚拟机无法启动,先查看vSphere任务栏中的错误信息，大多是磁盘文件锁定或vmx文件损坏导致，尝试用数据存储浏览器删除.lck锁定目录，或者用vmware-vdiskmanager修复磁盘，如果还是不行，将虚拟机从清单中移除再重新注册，不影响虚拟机磁盘数据。
ESXi主机网络正常但虚拟机挂起是什么原因
网络正常说明物理链路没问题,问题多半在虚拟交换机配置或虚拟机网卡驱动，检查虚拟交换机的安全策略是否启用了MAC地址欺骗限制，以及vMotion迁移时是否造成网络瞬断，虚拟机内部防火墙规则或安全软件异常也会导致“网络看起来通但实际无法访问”，建议重启前先重置网络栈。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/629358.html
