虚拟机卡住时，硬盘往往是首要排查对象，先看磁盘IO是否被打满，再用命令确认具体进程，最后检查存储配置与快照情况。
虚拟机卡住但CPU没跑满？先怀疑硬盘
不少朋友遇到虚拟机“假死”的时候，第一反应是去看CPU和内存，结果一看，CPU占用才30%，内存也够用，但系统就是点哪儿都没反应，这时候，硬盘IO瓶颈就是最大的嫌疑犯，虚拟机的所有读写操作都要经过宿主机硬盘，一旦后端存储响应变慢,整个虚拟机就像被按了暂停键。
行业共识认为，虚拟化环境里存储性能问题导致的卡顿占比相当高，尤其是多台虚拟机共用一个存储池的时候，想象一下，你住在一个大公寓里，下水管道是共用的，楼下邻居洗衣服，你家地漏就开始反水虚拟机抢硬盘也是这个道理。
怎么快速判断是不是硬盘卡住了？
- 看宿主机硬盘灯：如果是物理机，硬盘灯常亮不灭,说明IO非常繁忙。
- 进虚拟机里看资源监视器：Windows系统打开“任务管理器-性能-资源监视器”，看“磁盘”标签下的活动时间和队列长度。
- Linux虚拟机用iostat命令：直接输入
iostat -x 1，看%util这一列，如果一直超过80%,基本可以判定磁盘IO是瓶颈了。 - 感受一下“卡”的类型：如果是整机完全没反应，鼠标都动不了，通常跟IO无关，更可能是CPU vCPU过载或内存不足；如果鼠标能动，但打开程序、复制文件特别慢，那大概率就是虚拟机硬盘读写速度出了问题。
宿主机端看一眼，别只盯着虚拟机
很多人在虚拟机里排查半天，忘了宿主机才是根因所在，登录宿主机，用esxtop或top命令看一下整体负载，这里有个技巧：按u键再输入虚拟机名称，能单独看某一台虚拟机的存储使用情况，如果宿主机自身的存储延迟（Latency）已经飙到100ms以上，那问题就很简单根源在存储端,不只是某一台虚拟机的事。
虚拟机硬盘IO瓶颈的具体排查步骤
确认是大方向后，按顺序走这几步,基本能把问题定位到八九不离十。
第一步：查存储空间余量
这一步看似简单，但很多人忽略，虚拟磁盘文件（vmdk或vhdx）所在的数据存储空间如果剩余不足，虚拟机性能会急剧下降，尤其是快照文件，占空间且拖速度,检查方法很简单：
- vSphere环境：在存储页面看“已用空间”和“总容量”。
- Hyper-V环境：直接看存放虚拟磁盘的物理分区剩余空间。
- 命令行方式：在宿主机上执行
df -h查看挂载点使用率。
如果空间使用率超过85%，建议优先做存储清理或迁移，因为碎片化加空间不足会导致虚拟机持续卡顿,SSD也可能因剩余空间太少而性能衰减。
第二步：看磁盘队列长度与延迟
磁盘队列长度（Queue Length）是核心指标，它代表有多少IO请求在排队等待处理，数值持续超过2（单盘）或超过集群虚拟盘数量的一两倍，说明硬盘响应不过来了，延迟方面：SSD的延迟应该低于10ms，机械硬盘低于20ms，远超这个阈值,就是硬盘本身速度跟不上。
这里提醒一点：别只看平均值，要看峰值，有些硬盘平均延迟看着还行，但每隔几秒跳出一个几百ms的尖峰,同样会造成虚拟机卡顿。
第三步：锁定是哪个进程在疯狂读写
- Windows虚拟机：资源监视器里按“总(B/秒)”排序，能看到哪个进程的磁盘活动最高，常见的有Windows Defender定时扫描、SQL Server的日志写入、文件服务索引。
- Linux虚拟机：用
iotop或pidstat -d 1查看，前者更直观,能看到每个进程的IO速率和IO占比。
找到元凶后，针对性优化比如调整杀毒软件的扫描时间避开业务高峰期,或者给数据库加内存减少写盘频率。
第四步：检查虚拟机磁盘类型与控制器
有两类配置错误特别常见，这类问题在“虚拟机卡住怎么排查”的实战里几乎必现：
- 磁盘置备类型选错了：厚置备延迟高（Thick Provision Lazy Zeroed）初次写入要先清零，性能差劲；精简置备（Thin Provision）虽然省空间，但扩容时有额外开销，生产环境强烈建议用厚置备快速清零（Thick Provision Eager Zeroed）或使用全闪存存储并开启自动精简回收。
- SCSI控制器选错了：默认的LSI Logic SAS性能不错，但如果你装了PCIe NVMe虚拟磁盘，必须用NVMe控制器，不然速率跑不起来，Windows虚拟机建议把控制器设为VMware Paravirtual（PVSCSI）,IO吞吐量能提升一个档次。
存储层与快照问题的专项处理
这一步是为那些做完上面所有排查还没解决的朋友准备的。
快照过大？这是虚拟机卡顿的隐形杀手
很多运维同学给虚拟机拍了快照就忘了删，快照越攒越多，最后变成一个大黑洞，虚拟机的每次写入都要先更新快照文件，再同步到原盘，快照文件一旦超过虚拟磁盘大小的30%，运行时IO开销会非常明显，在vSphere里移除快照时，文件会做合并操作，
合并期间虚拟机还会更卡,建议把快照操作安排在业务低峰期。
存储多路径与HBA卡速率
再往下挖一层，物理存储链路也可能出问题，检查宿主机到存储阵列的链路是否冗余，HBA卡或网卡速率是否协商到最大档，有一个常见误区：存储侧做了RAID5，但随机写性能很差，多台虚拟机同时写数据库时就会拖垮整个存储，这种情况要么改RAID类型（RAID10随机写更强），要么增加更多的SSD缓存,要么给存储阵列加节点。
SSD出现静默错误
固态硬盘有个讨厌的问题，叫“静默错误”，也就是硬盘表面看着好好的，SMART信息也正常，但某个闪存块已经慢性死亡，每次读到它都要反复纠错，导致单次IO延迟暴涨到几百甚至上千毫秒，业内专家指出，这个问题在消费级SSD跑虚拟化场景时更容易出现所以虚拟机存储请务必用企业级固态硬盘,耐用性和一致性不是一个级别。
不同虚拟化平台的硬盘卡顿排查差异
不同平台的命令和排查路径差异很大,下面用一个表格来直观对比：
| 平台 | 查看IO延迟命令 | 查看进程IO方式 | 最可能的坑 |
|---|---|---|---|
| VMware ESXi | esxtop 按 d |
看虚拟机磁盘性能面板 | vSAN组件状态异常 |
| Hyper-V | 性能监视器（PerfMon） | Resource Monitor | VHDX文件碎片化 |
| Proxmox VE | iostat / atop |
iotop |
ZFS ARC缓存被挤占 |
| KVM/libvirt | virt-top |
pidstat -d |
qcow2镜像文件过大 |
Proxmox等裸机虚拟化的额外检查项
用Proxmox这类平台的朋友注意了，如果你开了ZFS存储，内存和ARC缓存的关系很微妙，ZFS会用掉宿主机一部分内存当缓存，内存不够时读操作直接走硬盘，性能断崖式下降，检查arcstat看cache命中率，如果命中率低于70%,建议加大缓存或降低虚拟机内存超分比。
虚拟机卡住时硬盘排查的完整命令速查
按顺序执行下面这些命令,从宿主机到虚拟机一层层剥开看：
- 判断整体存储延迟：
esxtop类型选d（storage device），查看DAVG/cmd和KAVG/cmd两列。 - 查看单个虚拟机IO：
esxtop下输u，查找目标虚拟机的%RD和%WR。 - Linux虚拟机内部
：
iostat -x 1四秒内连续观察五个采样，看svctm和%util。 - Windows虚拟机内部：
Get-Counter 'PhysicalDisk(_Total)% Disk Time'每秒刷新一次。 - 查看网络存储连接数：
esxcli storage nmp device list,看Path数量是否为双活。
如果以上所有命令查出来都没有异常，但虚拟机还是卡，那你可能需要看看是不是宿主机CPU调度或内存超分导致其他资源瓶颈，硬盘暂时可以排除，建议用vmware -v确认版本更新情况，旧版本ESXi的存储协议栈可能有已知bug，补丁更新有时就能顺手解决虚拟机卡死解决办法中的一大半问题。
日常预防：从根上降低虚拟机硬盘卡顿概率
排查做完了，还得讲讲怎么不让它再犯,以下几条是实践里性价比最高的方案：
- 把虚拟机的虚拟磁盘从MBR转为GPT并搭配UEFI引导，IO性能略有提升,还顺手解决了2TB容量限制的问题。
- 开启存储硬件的写入缓存（Write Back），但必须确保有电池保护或闪存保护,否则意外断电会丢数据。
- 定期清理虚拟机内的临时文件和更新缓存，不能让虚拟机内部磁盘空闲空间低于10%。
- 为数据库类虚拟机单独划分一块高性能存储池,避免和其他业务虚拟机抢IO。
- 开启磁盘Trim/SCSI UNMAP，让SSD回收空块,保持长期写入性能。
归根结底，虚拟机卡住时的硬盘排查思路，核心就是“从外到内、从存储到进程”先确认宿主机的存储系统是否健康，再进虚拟机看IO指标和具体进程，最后优化存储配置和快照策略，这套流程覆盖了绝大多数“卡死不报错”的诡异故障场景。
常见问题
虚拟机卡死和物理机卡死的硬盘表现有什么不同？
物理机卡死时，硬盘直接裸奔面对所有进程；虚拟机卡死时，你看到的硬盘其实是虚拟磁盘，它经过了一层虚拟化调度，因此虚拟机里看到硬盘100%忙碌，不代表宿主机硬盘真忙有可能是其他虚拟机在捣乱，或者虚拟磁盘文件所在的存储卷已过热降速，排查时优先看宿主机视角，再看虚拟机内部视角,两层数据对比才有意义。
虚拟机硬盘IO高但没卡死，需要马上处理吗？
不需要恐慌，但也不能放着不管，先看趋势，如果IO高只是持续一两分钟，关联某个定时任务（比如备份或扫描），那属于正常现象，如果持续半小时以上不见回落，建议按数据库或日志类进程的负载来规划扩容，否则高峰期随时可能从“慢”滑向“卡死”。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/628088.html
