把 70 GB 的 Win7 虚拟机压到 41 GB：快照、清零与收缩实战

一、起点：一个只增不减的文件#

D 盘快满了。查下来最大的一块不是代码、不是资料，而是一个 Win7 虚拟机目录：69.70 GB。

这台机器的虚拟盘只有 80 GB（167,772,160 扇区 × 512 字节），文件却占了 69.7 GB —— 而客户机里实际用掉的空间远不到这个数。

问题的根源是一个很多人没意识到的机制：

精简置备（thin / sparse）的虚拟磁盘，客户机里写过一次的块，就永久占住了。你在 Windows 里删文件、清缓存、卸软件，宿主机上的 .vmdk 一个字都不会少。

换句话说，虚拟机磁盘文件的体积记录的是”历史高水位”，不是”当前使用量”。

二、先看清家底：三个数决定你能省多少#

动手前先确认三件事，否则后面全是白忙。

① 磁盘是精简置备还是预分配？ 只有精简置备才谈得上”收缩”。

读 vmdk 头部的嵌入式描述符就能看出来（前 4 KB 就够）：

1
$fp = 'D:\vms\Win7 X64\Windows 7 x64.vmdk'
2
$fs = [IO.File]::OpenRead($fp)
3
$buf = New-Object byte[] 4096
4
$null = $fs.Read($buf, 0, 4096); $fs.Close()
5
$txt = [Text.Encoding]::ASCII.GetString($buf)
6

7
if ($txt -match 'createType="([^"]+)"') { 'createType = ' + $Matches[1] }
8
if ($txt -match 'RW (\d+) SPARSE')      { '容量 = ' + [math]::Round([int64]$Matches[1]*512/1GB,1) + ' GB' }

输出 monolithicSparse = 精简置备，可以收缩；如果是 flat / preallocated，得先转换（vmware-vdiskmanager -r）。

② 快照链有多长？ 读 .vmsd 文件，snapshot*.parent 字段就是链条的父子关系：

顺着 parent 一路往上找，就能还原出 base ← delta1 ← delta2 的完整链。

③ 有没有 vmem？ .vmem 是”带内存的快照”存下来的内存镜像，大小≈虚拟机内存。开机状态下打的快照，每个都会白占一份内存大小的空间。 这台 4 GB 内存的机器，两个快照就是 8 GB。

三、第一步：先扔掉 8 GB 的内存镜像#

.vmem 唯一的作用是”精确定点恢复那一刻的运行现场”。如果只需要”回到那天的磁盘状态”（冷启动引导），这 8 GB 毫无价值。

两种方式让它消失：

• 恢复快照后正常关机：从挂起状态启动 → 客户机里 Shut Down → 挂起内存被丢弃，vmem 自动删除，快照本身仍在（变成”仅磁盘状态”快照）
• 直接删除快照：连内存镜像带增量链一起处理

这一步的收益是确定的、立刻可见的：8 GB。

四、第二步：删快照 ≠ 省下一整个 delta#

这是最容易误判的地方。假设链是 base ← delta1 ← delta2：

所以”删快照”的真实收益是：vmem（确定）+ 冗余块（不确定）+ 后续能收缩的上限（很大）。

这台机器的实测路径：

到这里累计已经省下 23.9 GB，而客户机里的文件一个都没动。

五、第三步：客户机内部清理（这一步决定天花板）#

前两步只是”清理账本”，真正能把文件压小的前提是客户机里有大量可回收的空闲块。

我在 Win7 里跑了一个清理脚本，核心动作按收益排序：

1
:: 1) 磁盘清理（含系统文件），注册全部项目后静默执行
2
for %%K in ("Active Setup Temp Folders" "Downloaded Program Files" ^
3
            "Internet Cache Files" "Previous Installations" "Recycle Bin" ^
4
            "Setup Log Files" "System error memory dump files" ^
5
            "Temporary Files" "Thumbnail Cache" "Windows Upgrade Log Files") do (
6
  reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\%%~K" ^
7
          /v StateFlags0777 /t REG_DWORD /d 2 /f >nul 2>&1
8
)
9
cleanmgr /sagerun:777
10

11
:: 2) Windows Update 缓存
12
net stop wuauserv & net stop bits
13
rd /s /q "%SystemRoot%\SoftwareDistribution\Download"
14
md  "%SystemRoot%\SoftwareDistribution\Download"
15
net start wuauserv & net start bits
16

17
:: 3) 临时文件 / 缩略图 / 转储
18
del /f /s /q "%SystemRoot%\Temp\*.*"
19
del /f /s /q "%TEMP%\*.*"
20
del /f /s /q "%LOCALAPPDATA%\Microsoft\Windows\Explorer\thumbcache_*.db"
21
del /f /s /q "%SystemRoot%\Prefetch\*.pf"
22

23
:: 4) 系统还原点（保留功能、删旧记录，常见能省 5~15 GB）
24
vssadmin delete shadows /all /quiet
25

26
:: 5) 关休眠（释放 hiberfil.sys ≈ 内存大小）
27
powercfg -h off

几个注意点：

• cleanmgr 的 StateFlagsNNNN 后缀必须和 /sagerun:NNNN 的数字一致，否则静默执行等于没跑
• vssadmin delete shadows 只删还原点，不关闭还原功能，属于低风险高收益
• Win7 没有 DISM /StartComponentCleanup，WinSxS 能清的部分走 cleanmgr 里的「以前的 Windows 安装」
• 脚本跑完一定要看 C: 的可用空间变化 —— 这才是后面能压出多少的依据

六、第四步：清零 + 收缩（顺序不能反）#

到这里虚拟机还是 46.85 GB，但里面可能有十几个 GB 是”已删除但没回收”的块。要让它真的变小，必须：

1. 客户机里把空闲块写成 0（wipe）
2. 宿主机上把”全 0 的块”从 vmdk 里释放（shrink）

跳过 ① 直接跑 ②，几乎不会省空间 —— 因为从宿主机看，那些块里仍然是”有数据的”。

1
& "C:\Program Files\VMware\VMware Tools\vmware-toolbox-cmd.exe" disk shrink C:\

1
# 客户机内：Sysinternals sdelete 清零空闲块
2
sdelete64.exe -z C:
3

4
# 宿主机：先关掉 Workstation 里这台 VM 的标签页（否则 .vmx.lck 锁会让 -k 失败）
5
& 'C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe' `
6
   -d "D:\vms\Win7 X64\Windows 7 x64.vmdk"   # 可选：整理碎片
7
& 'C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe' `
8
   -k "D:\vms\Win7 X64\Windows 7 x64.vmdk"   # 收缩

七、WSL 的 ext4.vhdx：同样的病，不同的药#

同一天发现 WSL 的虚拟盘也是同一个毛病：

1
# ① 让 Linux 把空闲块标记为 discard（同时归零）
2
wsl -d Ubuntu-24.04-FuXi -e sh -c 'fstrim -av; sync'
3
#  → /: 990.6 GiB (1063677743104 bytes) trimmed on /dev/sdd
4

5
# ② 关闭 WSL（vhdx 被独占锁定，运行中无法压缩）
6
wsl --shutdown
7

8
# ③ 用 diskpart 压缩 vhdx（需管理员）
9
diskpart
10
  select vdisk file="D:\wsl\Ubuntu-24.04\ext4.vhdx"
11
  compact vdisk
12
  exit

1
wsl --manage Ubuntu-24.04-FuXi --set-sparse true

八、账本：一天做完的收益#

耗时：快照删除与合并约 25 分钟，客户机清理约 15 分钟，shrink 3.5 分钟，WSL 压缩约 4 分钟。不用重装系统、不用迁移数据。

九、我踩过的五个坑#

1. 以为”删一个快照就省一个 delta” 实际是折叠。delta 里独有的数据会并进父级，父级文件反而变大。真正确定能省的是 vmem 和”被覆盖的冗余块”。

2. 不清零就直接 -k 跑完发现文件只小了 200 MB。因为空闲块里还是旧数据，VMware 无法判定它们可释放。

3. VM 标签页没关，-k 报”文件被占用” .vmx.lck 存在就说明 Workstation 还打开着这台 VM。哪怕电源已关，也要把标签页关掉。

4. 备份盘的”虚假容量” 顺手体检了移动硬盘：文件实际 383.9 GB，已用却是 505.7 GB —— 差了 122 GB，全是 exFAT 大簇（128 KB）在几十万个小文件上的浪费。用 exFAT 存源码级小文件，等于白扔容量。

5. 忘了”压不掉的在用数据” 收缩前先看客户机里到底用了多少。如果 40 GB 里 35 GB 是真实安装的软件，最多只能压出 5 GB —— 这时候该做的是卸载/迁移，而不是反复 shrink。

十、可复用的检查清单#

写在最后#

虚拟机瘦身的本质不是”压缩”，而是把”宿主机以为被占用”和”客户机实际在用”这两笔账对齐。

对齐的方式只有两条：把不用的东西真的删掉（客户机内清理），以及把删掉之后留下的空洞明确告诉宿主机（wipe + shrink）。中间所有关于快照的纠结，都是在这个基础上做减法。

如果你的虚拟机也已经跑了几年、目录里出现 -000001、-000002 这种文件，建议先按第二节的三个数算一遍 —— 多数情况下，能省的空间比你以为的多，但省法比你以为的绕。