虚拟机死机，多数情况不是虚拟机本身坏了，而是宿主机先在内存、磁盘 I/O 或虚拟化驱动这三处撑不住了；先抓日志锁定层级，再动手处理，比直接重启省事得多。
控制台灰屏、远程桌面卡住、鼠标能动但点什么都没反应，遇到这种场面，很多人的第一反应是直接重启，重启这个动作没错，但重启前那两三分钟恰好是获取证据的最佳时间窗口，日志一丢，问题就变成了“偶发故障”,下次还得再猜一遍。
先分清死在哪一层，别急着点重启
虚拟机死机其实分三种层级，处理路径完全不同，判断错了层,后面全是白费功夫。
三种典型症状与对应层级
| 现象 | 最可能卡住的层级 | 优先检查什么 |
|---|---|---|
| 远程桌面黑屏，鼠标能移动但点击无响应 | Guest OS 内部 | 系统事件日志、dmesg、CPU 抢占情况 |
| 虚拟化平台控制台显示虚拟机“无响应” | 宿主机资源层 | esxtop 里的 %RDY、内存状态、存储延迟 |
| 整台宿主机 SSH 掉线、管理口也连不上 | 宿主机硬件或内核 | iLO/iDRAC 硬件日志、MCE 报错、RAID 卡状态 |
| 只在开 3D 应用或切换远程协议时死 | 显卡驱动或显示协议 | 关闭 3D 加速、改用控制台直连测试 |
重启前值得保存的两样东西
- 宿主机侧：ESXi 执行
vm-support打包日志；Hyper-V 导出事件查看器中的 Hyper-V-Worker 与 Hyper-V-VMMS 日志。 - Guest 侧：Windows 打开“启动和故障恢复”，确认已生成内存转储；Linux 确认 kdump 已启用并留下 vmcore。
这两样东西加起来通常不到一百兆，却决定了后面是“一次修好”还是“反复返工”。
虚拟机挂机死机怎么解决？按这五步从软件查到硬件
顺序不能乱，先查最便宜、最容易验证的软件层,再往硬件走。
第一步：确认宿主机有没有触发 OOM
Linux 宿主机执行 dmesg -T | grep -i -E "out of memory|oom|mce|hung task"，再配合 journalctl -k --since "1 hour ago" 看时间点是否对得上，只要出现 OOM killer 记录,基本可以判定是内存分配超过了物理上限。
处理办法很直接：把虚拟机总内存控制在物理内存的 80% 以内，给宿主机留出余量，内存可以超分，但超分之后靠交换分区或内存压缩顶着,性能会在某个临界点突然下降。
第二步：看 CPU 就绪时间
ESXi 上用 esxtop，按 c 切到 CPU 视图，重点看 %RDY，持续高于 10% 说明 vCPU 排队严重，vCPU 总数给多了，业内专家指出，vCPU 与物理核心的比例控制在 1:4 以内比较稳妥，数据库类负载建议不超过 1:2。
第三步：看存储延迟
iostat -x 1 看 %util 和 await，虚拟机磁盘延迟一旦长期高于 20 毫秒，Guest 内部就会出现大量 I/O 等待，表现出来就是“系统假死”，同时检查虚拟机磁盘是不是精简置备，高写入场景下精简置备的元数据开销会明显放大延迟,改成厚置备延迟置零或厚置备立即置零往往能缓解。
第四步：看快照与磁盘空间
快照链过长是隐藏的常见原因，每多一层快照，写入就要多穿一层 delta 磁盘，VMFS 数据存储剩余空间低于 10% 时，快照合并容易失败，虚拟机会直接卡在“合并中”，处理顺序是：先删掉不用的旧快照，再确认剩余空间,最后才考虑扩容。
第五步：再查硬件
前面四步都干净，才轮到内存条 ECC 错误、RAID 卡电池失效、电源功率不足、机箱散热，硬件问题通常伴随宿主机整体不稳定,而不仅是单个虚拟机出事。
实体机正常，虚拟机一开就死机？重点查这四处
物理机跑测试一切正常，一装进虚拟化平台就出问题,这类情况排查思路和上面不同。
嵌套虚拟化没开全
在虚拟机里跑 Docker、WSL2 或另一套虚拟化平台，必须开启嵌套虚拟化，VMware Workstation 在虚拟机设置里勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”；ESXi 需要在虚拟机选项里勾选“向客户机操作系统公开硬件辅助虚拟化”；Hyper-V 执行 Set-VMProcessor -VMName 名称 -ExposeVirtualizationExtensions $true，漏掉这一步，Guest 一加载虚拟化驱动就会崩。
内存分配碰到物理上限
给虚拟机分配的内存加上宿主系统占用，超过了物理总量，表现是开机几分钟内就卡死,日志里能看到内存压力告警。
显卡 3D 加速冲突
关闭虚拟机设置里的 3D 加速，改用基础显示驱动测试，远程桌面协议切换时死机的,多半是这一项。
杀毒软件与备份代理
Guest 内安装的实时扫描、卷影复制类备份代理，会在大文件写入时锁住磁盘，临时停掉再复现,能快速确认。
VMware与Hyper-V虚拟机死机原因对比
两套平台的日志位置和调优重点差别不小,混着看容易走弯路。
| 维度 | VMware（ESXi/Workstation） | Hyper-V |
|---|---|---|
| 日志位置 | /var/log/vmkernel.log、虚拟机目录下 vmware.log |
事件查看器 Hyper-V-Worker、Get-VM 状态 |
| 内存机制 | 支持超分，超分过多触发交换 | 动态内存，需设启动内存与最大值 |
| 嵌套虚拟化 | 勾选“硬件辅助虚拟化” | Set-VMProcessor -ExposeVirtualizationExtensions |
| 快照机制 | 快照链过长导致 I/O 放大 | 检查点合并失败多见于空间不足 |
| 高频诱因 | 内存超分、存储延迟、数据存储空间不足 | 动态内存参数不当、集成服务版本过旧、检查点堆积 |
行业共识认为，跨平台迁移后的死机，先对齐集成服务或 VMware Tools 版本,再谈性能调优。
虚拟机死机后数据怎么恢复？先保住磁盘再谈修复
顺序错了会丢数据。
- 立即停止对原盘的任何写操作。 不要在故障虚拟机上反复启动系统,每启动一次都可能覆盖残留的日志和文件系统元数据。
- 整盘复制出来。 关机后把 vmdk、vhdx 或 qcow2 连同快照文件一起复制到另一块存储,后续所有操作都在副本上做。
- 以只读方式挂载。 Linux 用
mount -o ro,noload挂载 ext4 副本，避免日志回放改动数据；Windows 用只读方式挂载 VHD。 - 优先做文件级恢复。 用 testdisk、photorec 或商业恢复工具扫描副本，先把业务文件捞出来,再考虑修复系统盘。
- 快照别急着删。 存在多级快照时，先确认父盘与 delta 盘的依赖关系,盲目合并可能直接损坏整条链。
云主机上跑虚拟机死机，排查费用该怎么算
云服务器里再套一层虚拟化，责任划分往往是争议点，云厂商的基础设施故障通常由平台承担，但 Guest 内部配置引发的死机不在保障范围。
排查费用大致分三档：云厂商高级支持一般按年订阅，不单次计费；第三方运维按工时或按次报价，简单日志分析通常在几百元量级，涉及数据恢复会明显上浮；自建机房则主要是人力和备件成本，真正省钱的做法是先自己按上文五步走一遍，把日志和复现步骤整理清楚再送修,能砍掉大量无效沟通。
日常怎么防，比出事再救划算
- 宿主机内存预留 20% 以上,别把物理资源吃满。
- 每台虚拟机的快照保留不超过两层,定期清理。
- 数据存储使用率设 80% 告警线,别等满了才处理。
- 虚拟化平台和集成服务保持同版本,升级前先在测试机验证。
- 关键业务虚拟机配置独立监控，盯住 %RDY、内存交换和磁盘延迟三项指标。
把这几条落到监控里,多数死机在真正发生前就有征兆。
虚拟机死机Q&A：三个高频问题
问：虚拟机死机后直接强制关机，会损坏虚拟磁盘吗？
有可能，强制断电时如果正在写元数据，vmdk 或 vhdx 的描述符可能不一致，更稳的做法是先尝试平台层面的“关闭电源”，无效再强制关机，事后用 vmkfstools -x check 或 Hyper-V 的检查磁盘功能验证。
问：Linux 虚拟机死机，日志里只看到 hung task，怎么继续定位？
hung task 说明有进程在内核态阻塞超过阈值，常见于存储无响应或驱动缺陷，先用 cat /proc/进程号/stack 看阻塞在哪个函数，再对照 iostat 和 dmesg 判断是 I/O 挂起还是锁竞争，开了 kdump 的机器直接分析 vmcore 更直接。
问：内存超分到底能不能用？
能用，但有边界，Web 前端、测试环境这类内存使用峰值不高的场景，适度超分可以提升密度；数据库、缓存、大数据节点建议不超分，VMware 的内存压缩和透明页共享能兜住一部分压力，一旦开始频繁交换，延迟上升的幅度会远超预期,这也是虚拟机挂机死机最常见的诱因之一。