VMware虚拟机无法启动？排查硬盘空间不足与VMDK膨胀问题

很长一段时间没写VMware排障类的内容了，结果这周就让我撞上一回：一台Windows宿主机上的虚拟机，头天晚上还好好的，第二天一早双击启动，VMware Workstation直接弹窗"磁盘空间不足，无法打开虚拟机"，紧接着又蹦出一个"The system cannot find the file specified"之类的错误。我第一反应是虚拟机配置文件损坏，排查了半天才发现，根子就是宿主C盘被塞到只剩几百MB，虚拟机压根没地方写内存交换文件。这台机器是典型的"数据全堆在虚拟机里，宿主盘常年不管"，一旦虚拟磁盘文件膨胀，整个宿主盘被吃干抹净，虚拟机就跟罢工的电梯一样卡在两层楼中间，上不去也下不来。

这类问题在大家日常使用VMware Workstation或Player时特别常见，尤其是习惯了"硬盘不够就加快照、文件大了就拖进去存"的同学。本文就结合这次排障经历，把"硬盘占用过大导致虚拟机无法启用"这条链路上的每一步都拆开说清楚：先讲怎么判断问题到底是不是硬盘满，再解释为什么虚拟机会把宿主空间吃到这么死，然后给出宿主机已经满了时的应急抢救步骤，最后聊聊怎么给虚拟磁盘本身瘦身，以及日常如何避免再踩同一个坑。

1. 先别急着重装系统：判断"无法启用"到底和硬盘满有多大关系

遇到虚拟机打不开，第一反应往往是修改VMX配置、重新注册虚拟机、甚至怀疑系统损坏干脆重装。但在动手做这些"破坏性"操作之前，我强烈建议你先花两分钟判断故障到底属于哪一类。我用这次故障和被它隐藏起来的事实证明，错误信息往往带有很强的迷惑性。

1.1 VMware可能给出的几类错误弹窗

根据我自己踩过的坑，硬盘空间吃满导致的启动失败，弹窗信息五花八门，常见的有：

1. "磁盘空间不足"或"Virtual disk file is larger than the available space"
2. "The system cannot find the file specified"——这个最容易让人误以为文件丢失
3. "VMware Workstation cannot connect to the virtual machine. Make sure you have rights to run the program and to access all directories"——一大串权限提示，实际就是工作区目录写入失败
4. "客户机操作系统已禁用 CPU。请关闭或重置虚拟机"
5. "VMware Workstation 不可恢复错误: (vcpu-1) Exception 0xc0000005"
6. 双击虚拟机完全没反应，日志里只留下一串vthread写入失败

当时我一度以为机器中病毒或者VMware许可证出了问题，因为搜索热词里也大量出现"vmware workstation无法连接到虚拟机""vmware 17许可证密钥""客户机操作系统已禁用cpu"这一类结果。实际上，这些看似各不相同的问题都可能有一个共同的底层原因：宿主系统磁盘可用空间归零，虚拟机既无法扩展内存交换文件(.vmem)，也无法更新快照或锁文件。

1.2 三步验证法：最可靠的判断思路

在动任何配置之前，用下面的顺序确认，能帮你节省起码一个小时的无效操作：

1.3 一个容易被忽略的细节：宿主机的系统分区和虚拟机所在分区不是同一个

注意上面表格里我说的是"塞满盘的那个分区"。很多人的虚拟机安装在D盘，Windows系统分区是C盘。即便D盘还剩50GB，如果C盘剩余空间已经见底，虚拟机依然可能起不来。因为VMware Workstation默认会把一些临时文件写到宿主系统的%TEMP%目录和用户的AppData目录下，这些文件包括：

• 日志文件
• 虚拟机套接字临时文件
• UI状态存储和崩溃转储文件

于是出现了一种非常神奇的情况：你打开虚拟机所在目录，发现D盘明明还很宽敞，可VMware就是报"无法写入"。学会把目光从虚拟机文件本身挪到整个宿主磁盘上，是这套问题排查的关键第一步。

2. 虚拟机的"虚胖"机制：为什么磁盘文件会越涨越大，把宿主空间吃干

搞清楚问题之后，自然要问：虚拟机文件到底是怎么一步步侵占宿主磁盘空间的？这就要从虚拟磁盘的工作机制讲起。别小看这部分原理，不懂它，你后面做任何清理都是在盲人摸象。

2.1 固定大小磁盘与动态增长磁盘的差别

VMware创建虚拟磁盘时，会让你选"立即分配所有空间"或"将虚拟磁盘存储为单个文件"、"将磁盘拆分成多个文件"等等。核心差异在于分配策略：

• 固定大小（厚置备）：创建时就占满规定大小。比如设定100GB，宿主机文件立即就是100GB。这种做法性能略好，但对空间不友好，而且一旦文件内容被删除，文件自身大小不会变，宿主磁盘依然显示占用100GB。
• 动态增长（精简置备）：一开始只有几十MB，随着虚拟机内部安装系统和存放数据，文件逐渐扩大，最大增长到你设置的上限。这种模式是大多数人踩坑的根源：设置上限时大手一挥写了200GB，实际只用了60GB，可文件系统会随着使用碎片化和快照蔓延，最终宿主文件突破你预期的大小上限，在宿主盘上留下一个巨大的洞。

热词里有人搜"可以设置占用硬盘存储吗"，答案是：可以，但默认配置下它多半不是你想的那种"限制死后不再增长"，而是"上限之内不设防地增长"。除非你在VMX配置文件里额外加一些参数，否则这个"大小设置"更像一个预算帽，而非实时占用强制值。

2.2 快照是空间膨胀的头号元凶

Windows系统里有一种"系统还原点"，VMware快照也类似于一个还原点。你在虚拟机里安装补丁或测试软件前创建快照，出问题后可以秒回滚到之前状态——这个设计听起来很美，代价却隐藏得很深。

VMware快照的实现机制是：快照创建后，原VMDK文件会立即变成只读的"父盘"，虚拟机后续的所有写入操作会被引导到一个新的"增量磁盘"，也叫差分盘或Redo。父盘文件大小保持不变，而增量盘从零开始持续增长。举个例子：

• 你有一个基础虚拟机，磁盘文件60GB
• 做了一次快照，产生一个增量磁盘文件，刚开始只有2GB
• 你在虚拟机的数据库或日志系统里折腾了三个月，增量盘可能膨胀到40GB、50GB，甚至超过基础盘的体量
• 如果你又在快照上创建快照，会形成一条快照链，每一层都可能是几十GB

问题来了：当增量盘膨胀到宿主分区剩余空间不足时，删除快照也不是一件轻松的事。因为删除快照意味着把增量盘中数据写回父盘，这个合并动作需要大量的临时空闲空间。空间越少，合并越失败；合并越失败，空间越少——经典的恶性循环。

2.3 内存交换文件、挂起文件和锁文件

除了主VMDK和快照增量盘，虚拟机目录下还会出现一些占用空间不小的附属文件：

• .vmem文件：当你开启"挂起虚拟机"功能，或虚拟机运行时异常，VMware会把虚拟机的内存状态写入这个文件。它的体积基本等于你分配给虚拟机的内存大小。分配了8GB内存，出现一个8GB的.vmem文件再正常不过。
• .vswp交换文件：在ESXi环境更常见，Workstation类产品也可能产生类似临时分页文件。它用来缓解宿主内存压力，占用的空间同样不容小觑。
• .lck锁文件目录：严格来说它本身不占大空间，但如果虚拟机关闭异常，目录里残留的锁文件会导致下次启动时VMware一直提示"正在使用中"或无法获取所有权。部分场景还会导致虚拟机配置信息反复读写失败，放大"无法启用"的观感。

2.4 日志和临时文件：隐藏的吃盘小角色

虚拟机运行时间长了，vmware.log文件会滚动更新，单看每个文件只有几百KB到几MB，但发生I/O错误后它会疯狂重试并记录大量重复信息。Windows宿主侧的%TEMP%以及VMware Workstation安装目录下也可能积累崩溃转储文件。配合Windows系统补丁缓存、睡眠文件hiberfil.sys、页面文件pagefile.sys，宿主的系统盘在不知不觉中就被啃到了只剩最后几百MB。

3. 宿主机空间见底时的紧急抢救：让虚拟机先跑起来的正确顺序

前面的判断和原理都清楚了，接下来的动作才最关键：在宿主盘已满、虚拟机无法启动的条件下，怎么一步步挤出救命空间，让系统先恢复可用状态。注意，这个阶段的目标不是彻底优化，而是"先让业务恢复"，因此所有操作都得按影响从最低到最高的顺序执行。

3.1 第一步：释放宿主系统侧的临时垃圾

如果C盘满了，最先清理的是下面这些几乎不需要承担风险的内容：

bash复制# Windows: 清理临时目录、Windows旧补丁缓存、回收站
cleanmgr /d C: # 调起磁盘清理，勾选"Windows更新清理"和"临时文件"

# Linux宿主: 查看哪个目录占用明显大
sudo du -xh --max-depth=1 /home | sort -rh | head -20

这一步通常能挤出几个GB到十几个GB不等，尤其是Windows系统，Windows Update缓存动辄占5GB以上。另外值得检查的是虚拟机目录上级的C:\Users\你的用户名\AppData\Local\Temp，VMware异常崩溃后经常在这里扔下几百MB到几GB的临时崩溃文件。清理时注意，如果VMware进程还在运行，直接删Temp文件可能导致奇怪的读写错误，所以先彻底结束vmware.exe相关进程再删。

3.2 第二步：用大文件扫描工具定位"隐藏的空间黑洞"

别再用资源管理器一个个点属性了，效率太低。我推荐Windows下用WizTree或TreeSize这类按扇区扫描的工具，Linux下用ncdu或du命令。扫描时重点看以下几个目录：

1. C:\ProgramData\VMware——VMware Workstation主程序的日志和缓存
2. C:\Users\[用户]\Documents\Virtual Machines——默认虚拟机存储位置
3. D:\VMs\——如果你把虚拟机放在这里，扫描它下面每个子目录里的.vmem、快照增量盘
4. C:\Windows\SoftwareDistribution\Download——系统补丁下载缓存
5. 已删除文件仍然占用的空间——有些程序占用大文件，删除时因句柄未释放导致空间不释放，表面上文件没了，磁盘空间却依然看不到。通过任务管理器关闭占用该文件的进程，或彻底重启来解决

3.3 第三步：处理残留锁文件和挂起文件

故障发生前如果虚拟机未经正常关机（比如宿主突然断电），虚拟机目录下会有多个以.lck结尾的文件夹。VMware靠这些锁文件夹来防止同一虚拟机的多开和冲突。异常断电后锁信息已经过期，但VMware仍按锁存在处理，于是虚拟机无法启动。

普通处理方式是在VMware界面提示"锁定失败"时选择"取得所有权"。如果界面操作无效，则需要手动处理：

1. 关闭VMware Workstation所有进程
2. 进入虚拟机目录，按名称排序，找出所有.lck文件夹
3. 删除这些文件夹前半部分内容安全吗？我建议先重命名成.bak，再启动试试。如果启动正常，说明锁确实过期了，直接删除；如果启动报新错误，再恢复回来排查
4. 同目录下如果有异常大的.vmem文件，并且虚拟机不是处于"挂起"状态，可以备份后先移走——它不是启动必需文件，而可能是上次崩溃残留的内存镜像

3.4 第四步：扩展宿主分区或迁移虚拟机目录

如果清理完上面所有垃圾后空间依然紧张，最直接的办法就是对宿主磁盘扩容：

• Windows：使用Disk Management或第三方分区工具，把相邻空闲空间合并到C盘
• 如果是VMware ESXi、PVE这类虚拟化宿主，需要先给虚拟机磁盘扩容，再在虚拟机内部用resize2fs或Windows磁盘管理扩展分区
• 不想动分区的话，另一个稳妥方案是把整个虚拟机目录移动到剩余空间更大的另一块硬盘

迁移虚拟机目录有个正式方法：在VMware Workstation里菜单"文件-打开虚拟机"选择VMX文件后，使用"文件-移动/复制"向导。但空间不足时向导往往也会失败，所以更推荐手动Robocopy或rsync完整复制，然后重新注册VMX文件。复制时务必连同.vmdk、.nvram、.vmx所有文件全部搬走，防止只复制了主文件却漏了快照增量盘。

3.5 系统层兜底：如果连虚拟机的运行都让宿主卡死怎么办

遇到过一种更惨的情况：宿主硬盘不仅满了，而且因长期占用达到100%，连鼠标操作都卡顿。这时候别硬扛着UI操作，建议你用纯命令行或安全模式完成第一步的清理。Windows下在启动时按F8进入带命令提示符的安全模式，执行cleanmgr或直接del /f /q C:\Windows\Temp\*，比在桌面里一层层点开资源管理器高效得多。

4. 给虚拟磁盘本体"瘦身"：回收空间从治本出发的三个步骤

应急启动解决之后，问题并没有真正结束。如果不把虚拟磁盘文件自身的"虚胖"治住，过不了几天又会重蹈覆辙。这一章讲的，就是真正释放VMware占用的硬盘空间、让虚拟机不再无限膨胀的核心操作。

4.1 虚拟机内部先清理：腾出"逻辑空间"而不是"物理空间"

很多人的清理顺序搞反了：直接从宿主机层面把某些虚拟机文件删掉。正确做法恰恰是先进入虚拟机内部，把客户机系统里的"垃圾"清理干净。这一步的作用是让VMDK文件内部出现大量空闲扇区，为后续压缩操作做准备。

具体动作包括：

1. 在虚拟机里卸载不用的软件
2. 清理临时文件、浏览器缓存、Windows更新缓存
3. 清空回收站
4. 对数据库或日志目录做压缩和归档
5. 到虚拟机系统"关闭"状态后，再处理虚拟磁盘本身

请记住一个核心原则：VMDK文件的大小变化，不完全依赖于虚拟机内部文件是否被删除。对于动态增长的VMDK来说，Unix/Linux客户机中删除文件，对应扇区会标记为可复用，但宿主VMDK不一定立刻缩小；Windows客户机如果启用了快照或有系统还原点，删除文件后对应扇区甚至会被某些服务持续占用。因此，做完内部清理之后，必须进行下一步的"归零"和"压缩"操作。

4.2 碎片整理与"零填充"：让可用扇区真正变成可回收扇区

在虚拟机内部，文件删除后剩余的扇区还需要被"归零"，VMware的压缩工具才能认出这些区域是空闲的，从而把它们从VMDK文件中移除。不同客机系统有不同的归零方式。

对于Windows客户机，我建议：

1. 在虚拟机设置里，将虚拟硬盘类型切换为IDE（如果原来是SATA/NVMe，某些工具兼容性更好）
2. 在虚拟机内安装并运行VMware Tools
3. 在虚拟机"我的电脑"上做一次完整碎片整理——但如果你用的是SSD，本身不需要传统碎片整理，此时改用VMware Tools提供的"Shrink"功能更直接

有一步容易被忽略：清理Windows客户机时，最好关闭系统还原、休眠功能。否则hiberfil.sys和还原点会占满大量空间，即使你做了碎片整理，这部分空间也是不可回收的系统文件。实际操作中可以通过在客户机内执行powercfg /h off关闭休眠，再检查系统还原设置，通常能额外释放出2~8GB空间。

对于Linux客户机，使用fstrim -v /或zerofree命令，在挂载状态下尽量把未使用的块填充为零。绝大多数现代Linux发行版都支持fstrim，它执行速度快，且不要求客户机关机。如果客户机是老的发行版，可以启动到单用户模式，再对对应分区依次执行zerofree /dev/sda1。

4.3 使用vmware-vdiskmanager压缩虚拟磁盘

完成了内部清理和零填充后，重头戏来了：关闭虚拟机，在宿主机上执行压缩命令。VMware Workstation安装目录下自带一个工具，路径类似：

bash复制# Windows宿主，假设VMware Workstation装到默认路径
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -k "D:\VMs\win10\win10.vmdk"

# Linux宿主
vmware-vdiskmanager -k "/home/user/VMs/ubuntu/ubuntu.vmdk"

参数-k的作用是压缩指定虚拟磁盘，也就是把动态磁盘中已标记为归零的区域释放出来。注意几点关键经验：

之一：这个操作要求宿主机有足够空间放临时文件。说白了，压缩VMDK会先创建一份临时副本，因此宿主机可用空间必须大于当前VMDK大小减去预计压缩后大小，否则命令会直接报"磁盘空间不足"并中止。所以我通常在压缩前先做好第一步和第二步的宿主垃圾清理。

之二：如果虚拟机有多个快照，直接压缩主VMDK是无效甚至危险的。压缩操作针对的是指定磁盘文件，而快照增量盘中的数据按时间线分散在多处。正确的处理顺序是先在VMware中删除快照或经过快照管理器合并，让虚拟机磁盘数据重新归拢到单一VMDK，然后再执行压缩。反过来操作会把快照链搞得更乱，甚至让虚拟机无法启动。

之三：如果虚拟磁盘被配置成"拆分成多个2GB文件"，压缩前请先备份VMX文件，然后正确指定主VMDK路径。多个子文件场景的压缩耗时会成倍增加，建议在虚拟机设置里先把磁盘切换成"单个文件存储"，或者干脆用第4.5节提到的克隆法来做整体瘦身。

4.4 Windows客户机里的Shrink选项

很多人不知道，VMware Tools自带"Shrink"功能，它本质上帮你在客户机内部做碎片整理加零填充，然后在线通知宿主回收空间。操作路径是：

• 在已开机的虚拟机里，右键点击VMware Tools托盘图标，选择"Shrink"
• 或在VMware菜单中选"虚拟机->设置->硬盘->工具->压缩"

这个Shrink过程只对未挂起且磁盘尚未有快照的虚拟机有效，速度视磁盘大小而定，动辄几十分钟到数小时。我个人的经验是，它适合处理10~30GB的中小型客户机磁盘；如果你有上百GB的数据库虚拟机，还是老老实实走vmware-vdiskmanager -k，效率更高且更容易监控进度。

4.5 全克隆：规避复杂压缩问题的最省心方案

如果虚拟机快照链已经乱成一团，你又不确定压缩操作会不会破坏数据，还有一个更稳妥、在实战中屡试不爽的终极方案：把虚拟机作为模板，做一个完全克隆，然后把旧虚拟机删掉。

在VMware Workstation中右键虚拟机->"管理"->"克隆"，选择"创建完整克隆"。完整克隆会生成独立于原虚拟机的新VMDK文件，这意味着：

• 它不会继承原虚拟机的快照链
• 新磁盘文件只有实际数据占用的容量
• 整个克隆过程等于把所有数据重新写入干净的新容器

克隆完成后，把新虚拟机目录移到宿主机里，测试能正常启动，再把旧虚拟机删除。这一步处理复杂膨胀和快照损坏非常有效。缺点是耗时较长、需要宿主机暂时有足够空间同时容纳新旧两份文件——但这个空间需求通常远小于硬着头皮去合并损坏快照所需的空间。

4.6 要不要压缩"预分配固定大小"的虚拟磁盘？

如果你当时创建磁盘时选了"立即分配所有空间"，压缩操作意义有限。固定大小VMDK在宿主机上始终占满你设置的上限，内部哪怕全删空了也一样。对这种磁盘，想真正回收空间，只有两条路：

1. 用克隆法创建新磁盘，把数据搬过去，再删除旧磁盘
2. 在虚拟机设置里直接替换磁盘文件，把固定大小改成动态增长，然后按第4.3节压缩

换句话说，固定大小磁盘拿到的是一张"固定金额的储蓄卡"，瘦身必须把资金转到新卡里去，没法在原有账号上"取出空气"。

5. 从源头卡住空间膨胀：让问题不再复发的日常配置清单

最后一个章节，也是最容易被忽略的章节。前面所有操作都像灭火，而真正能让你以后不再半夜爬起来救砖头的，是日常的配置和习惯。这里我不讲太多空泛的建议，只给出一套直接照做的清单。

5.1 给VMware设置可用的临时目录和磁盘缓存边界

很多人在乎大VMware文件放在哪里，却忽略了VMware Workstation自身工作目录的占用。

做法：菜单"编辑->首选项->工作区"，把虚拟机默认目录放到非系统盘。VMware的"配置文件位置"在Linux上习惯放~/.vmware，Windows上隐藏在AppData\Roaming\VMware。虽然没有必要全搬，但如果你发现系统盘被VMware相关的缓存拖累，可以修改系统环境变量TMP和TEMP指向大分区。

5.2 快照的使用纪律：快照是临时工具，不是备份

这是所有建议中我最想强调的一条。

快照是一个非常容易被误用的功能。很多人创建了快照之后再也没管过，三个月后快照链已经膨胀到宿主盘灾难现场。正确做法包括：

• 只在做重大变更前创建快照，变更完成后48小时内确认系统正常，然后立即删除快照
• 同一时刻保留的快照数量尽量不超过两个
• 不要把快照当备份——快照不保护宿主盘损坏或虚拟机目录误删的情况，它只保护客户机系统内部逻辑错误

如果确实需要长期保留多个可回滚状态，建议定期把虚拟机关机，对VMDK做一次克隆快照，而不是通过Workstation原生快照无限制叠加。

5.3 虚拟机磁盘空间的预算制度

在创建虚拟机时，不要贪大。我给团队常用的口诀是："系统盘大小设成你预期占用量的1.5倍，数据盘大小按业务最新实际数据规划并预留30%缓冲"。一个SQL Server虚拟机往往只需要系统盘120GB、数据盘500GB，而不是一开始就直接开1TB。磁盘上限设得越大，动态VMDK的"潜在虚胖"空间也越大，对宿主盘的长期压力也越高。

另外，在给虚拟机分配磁盘上限时，要注意把虚拟内存、pagefile和应用程序临时文件都算进去。Windows虚拟机中pagefile默认可能让系统C盘占用量比预期多出8~16GB。

5.4 宿主磁盘可用空间的监控与预警

在宿主系统层面做好空间预警，是防止"磁盘满导致无法启用"的最有效手段。Windows上可以用计划任务，定期执行PowerShell脚本：

powershell复制$drive = Get-PSDrive C
$freeGB = [math]::Round($drive.Free/1GB,2)
if ($freeGB -lt 20) {
    Write-Host "C盘剩余空间不足20GB，当前剩余: ${freeGB}GB"
    # 可在此处接入邮件、钉钉或微信通知脚本
}

如果是有一定规模的环境，建议直接在宿主机上装一个小的监控服务，对每个分区的可用空间做阈值告警。低于30GB就告警，低于10GB发紧急通知，而不是等虚拟机全部罢工再去抢救。

5.5 关闭不需要的暂停状态文件

"挂起虚拟机"功能虽然方便，但它会在磁盘上长期持有与虚拟机内存大小相同的.vmem文件。如果几台虚拟机都处在挂起状态，一两百GB的空间瞬间就没影了。建议在非必要场景下，改用"关机"而非"挂起"。如果你发现某个挂起的虚拟机你已经很久没恢复使用了，直接把它丢弃挂起状态并强制关机，比一直留着那个内存镜像文件理智得多。

5.6 定期清理包含日志和临时文件的虚拟机内部积灰

最后落脚到最朴素的一层：虚拟机内部的数据总量管理。无论是Windows虚拟机还是Linux虚拟机，数据库事务日志、应用日志、容器镜像、构建缓存，都是典型的"越积越肥"数据。建议每季度固定做一次虚拟机内部巡检，清理大日志文件，并同步删除无用快照。平时系统整体空间不足时，这些内部垃圾往往是被第一个忽略、却最容易被安全回收的部分。

这轮排障下来，我最大的感受是：VMware虚拟机因硬盘占用过大无法启动，本质上不是VMware软件的bug，而是宿主存储管理出了问题。虚拟磁盘的"虚胖"、快照的无序叠加、.vmem和日志的悄悄积累，每一个都在一点点吞噬宿主分区，直到最后零点几GB把启动流程卡死。处理这类问题最要紧的是顺序：先判断确实是空间问题，再紧急释放宿主空间，接着用压缩和克隆手段给虚拟磁盘本体瘦身，最后靠配置纪律和监控避免再次发生。以后你遇到VirtualBox或VMware虚机启动失败，千万别一上来就怀疑系统坏了，先低头看一眼磁盘剩余空间，八成问题就解决了。