虚拟机突然死机，数据大概率能恢复，但恢复成功率取决于你接下来几步操作是否正确，先别急着强制重启，先冻结状态、保留现场，再谈排查和数据抢救。
虚拟机突然死机怎么办：第一步永远不是重启
宿主机还活着,虚拟机屏幕却卡成一张画，鼠标不动，SSH连不上，控制台也没反应，这时候最错误的操作就是直接点“重启客户机操作系统”或者从宿主机执行强制关机。
我把正确操作拆成三步：冻结、快照、备份配置文件。
先冻结虚拟机CPU和I/O，防止磁盘写入造成二次伤害
这一步的目的是让虚拟机停止一切写操作,保住现场。
- 在VMware ESXi主机上，先确认虚拟机对应的vmid：
vim-cmd vmsvc/getallvms
- 然后冻结这个虚拟机：
vim-cmd vmsvc/suspend [vmid]
suspend是把内存状态挂起到磁盘,比关闭安全得多，如果虚拟机已经在“假死”状态，这个操作可能耗时较长，但值得等。
如果是Proxmox VE，用：
qm suspend [vmid]
如果是KVM/libvirt，用：
virsh suspend [vmname]
冻结完成后,再给虚拟机目录拍一个文件级快照，也就是复制整个虚拟磁盘文件这一步是为后面排查争取时间，注意，在业务高峰期做磁盘复制会占用额外I/O，但是和直接死机丢数据相比，这点代价完全值得。
死机之后的“黄金半小时”不要乱点恢复
很多运维人员会下意识去点“重置虚拟机”，这个动作等于把内存里的未落盘数据清零，如果当时数据库或中间件还有脏页没刷盘，这些数据就彻底没了。
业内专家指出,虚拟化场景下的数据丢失，相当一部分原因是人为操作，而不是虚拟化平台本身，冻结后不要乱动，先做下面这些事：
- 不要让虚拟机自动启动,ESXi默认策略如果是开机自启，先把开机策略关掉
- 备份虚拟机配置文件vmx或conf到本地
- 有分布式交换机配置的,顺手导出一下网络配置
虚拟机死机数据能恢复吗：分清三种场景
能不能恢复,首先看死机发生在哪个层面，再对应到不同的恢复路径。
虚拟机卡在“无响应”但进程存活，数据恢复概率最高
这种属于软死机,Guest OS还活着，但对外服务端口不响应，可能在处理极端负载或者内核卡在某个IO等待上。
处理方式：
- 等待几分钟,让IO超时自动恢复
- 从宿主机尝试发送NMI（非屏蔽中断）事件，触发guest内核panic后自动重启，使用系统下的core dump来做诊断
- 如果客户机内有数据库主从架构,优先让备库接管流量，然后对原节点做内存转储分析
这种场景下,磁盘文件系统没有损坏，恢复概率接近百分之百。
虚拟磁盘文件损坏导致虚拟机起不来，属于中等风险
典型表现是：从控制台看到虚拟机黑屏或者卡在BIOS，磁盘文件报无法识别的格式。
这时候不要重建虚拟机,先用qemu-img check或VMware的vmkfstools -R做文件检查，以VMware为例：
vmkfstools -R /vmfs/volumes/datastore1/xxx/xxx.vmdk
有快照的,优先检查增量盘是否完整，常见的VMDK链式快照逻辑是：子盘先写，老盘不动，如果子盘丢了，恢复会非常麻烦。
宿主机磁盘物理故障导致虚拟机彻底无法挂载，需要底层恢复
这种就需要把物理磁盘拆出来挂到另一台机器上。在拆盘之前，务必确认RAID卡没有掉线，否则直接重建阵列会触发数据覆盖。
选择恢复工具时,优先尝试开源方案或者厂商自带工具，不要一上来就找偏门的“硬盘恢复软件”，很多第三方工具在扫描VMDK格式时会写乱metadata，反而降低恢复成功率。
强制重启后数据丢了，还能找回未落盘数据吗
如果没有做内存转储,未落盘的数据理论上无法找回，所以不少虚拟化平台都建议给核心虚拟机配置持久化内存或BBU电池保护，这能显著降低意外断电带来的数据丢失风险。
虚拟机突然卡死原因排查：按频率从高到低排列
排查原因不是抱着日志硬啃,而是按概率顺序排查，优先看最常见的几个。
宿主机资源超分配，是虚拟机卡死的第一大原因
很多小机房和测试环境,宿主机内存超分严重，当多个虚拟机的负载峰值叠加时，宿主机出现内存回收风暴，内核线程卡在kswapd上，表现为所有虚拟机同时变慢甚至假死。
排查命令：
esxtop -d 1 # 观察CPU和内存指标重点看%RDY（处理器就绪等待时间）和%WAIT，如果%RDY持续超过20%，说明CPU严重争抢，这台宿主机的vcpu分配过多。
行业共识认为,CPU超分比控制在1:2以内，内存尽量不要超分，如果你用的是生产环境，别把内存超分当成默认配置。
存储层IO延迟突然升高，是卡死的第二大原因
虚拟机没崩溃,但所有涉及读写的操作都卡住，多半是存储链路出问题了，常见诱因：
- 同一台存储上,另一台虚拟机在做全量备份或快照整合
- SAN光纤交换机端口故障导致链路倾斜
- 本地磁盘快满,VMFS文件系统碎片化严重
观察指标：
iostat -x -m 1
重点看await和%util，如果await超过100ms而%util没满，说明存储对端有瓶颈，不在宿主机这层。
网络层面丢包导致“看起来死机”
这个场景容易被误判,虚拟机窗口还能动，但远程工具连不上，业务上报超时，看起来像死机，其实网络丢包。
排查方式：
- 查看vSwitch上行链路是否出现链路抖动
- 用
esxcli network nic stats get看物理网卡的RX/TX drop计数 - 检查是否勾选了安全策略里的“伪造发送”，有些安全设备会因MAC地址学习问题丢掉vMotion后的数据包
迁移、快照合并操作引发的卡死
做过vMotion或Storage vMotion后，虚拟机内部网络可能出现瞬断，ESXi主机在迁移完成后有一个网卡热插拔流程，部分旧版本驱动不支持这个操作，会导致guest系统卡死。
如果你正在做迁移后虚拟机重启/卡死排查，建议先向供应商确认驱动兼容性矩阵，然后再查应用日志。
虚拟机死机故障模拟与验证策略
与其等到宕机再处理,不如在测试环境里故意制造卡死场景，验证恢复流程是否有效：
制造CPU饥饿场景
在测试主机上,用多个虚拟机打满两倍的CPU资源，观察esxtop中的%RDY升降，确认宿主机的调度器阈值在哪里。
制造存储抖动场景
用iometer或fio向同一个存储卷发起高深度随机读写，然后同时启动一台新虚拟机，看存储延迟是否触发全局卡顿，这样能直接测试存储QoS配置是否生效。
制造内存压力场景
登录虚拟机内部,用stress --vm 2 --vm-bytes 4G拖垮内存，然后在宿主机上执行vim-cmd vmsvc/suspend，验证挂起到磁盘需要多长时间，是否能在5分钟内完成。
做完这些测试,你的恢复路径才算真的靠谱。
虚拟机死机后的长期预防与配置加固
如果虚拟机频繁“偶尔卡一下”，别老盯着guest系统重装，先看宿主机架构。
- ESXi主机上,给核心虚拟机开启高可用重启策略，例如VMware HA的“虚拟机监控”功能，设置错误次数阈值，自动重置虚拟机
- Proxmox VE环境下，给对延迟敏感的业务启用
msi中断直通，避免虚拟化层把中断处理搅成一团 - 存储层面,把数据库虚拟机磁盘的IO调度策略从默认时间片改回noop或none，减少虚拟化层的IO合并延迟
虚拟机死机怎么恢复：完整Q&A
问：虚拟机死机强制关机以后再开机，系统文件会损坏吗？
强制关机会中断文件系统日志,损坏概率中等，Ext4和XFS都有日志回放机制，多数场景下开机后能自动修复，但如果你没等日志回放完成就再次关机，那文件系统的核心元数据就可能被破坏，此时再用fsck抢救难度会明显提升。
问：虚拟机突然卡死原因最常见的排查顺序是什么？
按顺序排查宿主机CPU争抢、存储IO延迟、网络链路丢包、迁移或快照合并操作，先看宿主机再进客户机，先看硬件再翻日志，整体来看，虚拟机突然卡死原因排查需要参考宿主机和存储两个层面的监控数据，不要只盯着客户机内部日志。
问：VMware虚拟机死机数据恢复，有什么特别注意？
先确认该虚拟机是否有独立快照和备份,不要直接在数据盘上格式重建文件系统，VMware的VMDK支持在另一台ESXi主机上做数据提取，你可以把数据盘单独挂载到临时虚拟机，然后以只读方式拷贝数据，据VMware官方公开资料，VMDK文件处于关闭状态下读取最安全，所以务必先卸盘再挂载。