VMware精简磁盘空间回收：VMFS5下Thin盘瘦身实操-开发者社区

简介：面向 VMware 虚拟化运维人员与存储管理初学者，这份 408KB 的 docx 文档聚焦 Thin 精简磁盘空间回收难题，围绕 VMFS5 不支持自动回收空间的现实限制，梳理 SDelete 清理与 Storage VMotion 迁移两条解决路径，并补充适用条件、停机要求与格式转换等注意事项。包内共 1 个 docx 文件，内容以问题现象、环境说明、处理思路和结果验证为主线，便于读者理解精简卷空间占用与回收逻辑。该资料已有 2022 人学习，适合需要处理 VMDK 空间未释放、Thin 磁盘回收及 ESXi 存储维护任务的读者参考，可作为日常运维中的排查思路与方案对照材料。

1. 从一块 36.7G 的 VMDK 说起：Thin 磁盘删了文件为什么不瘦

一台跑着 Server 2012 R2 的虚拟机，系统里翻来覆去只放了 27.8G 的东西，数据存储上那个 VMDK 却稳稳占着 36.7G。清过临时目录、删过旧日志、回收站也倒了，这个差值一点没动——这就是 VMware 精简磁盘空间回收最典型的现场，也是 Thin 磁盘最容易被误解的地方：删文件在 guest 里只是把簇标记成空闲，VMFS5 根本不认这件事，块该占还占着。

盘越用越虚，备份越来越慢，克隆越来越久，等到数据存储亮红灯才想起来处理，往往已经挤不出停机窗口。这套流程适合手上有 Thin 虚拟机、跑在 VMFS5 上、并且能安排出一次关机或一次在线迁移窗口的人。两种回收路子各有代价，下面按「先盘环境、再动手、最后验证」的顺序拆开记。

2. 回收前的环境盘点：磁盘格式、VMFS5 和停机窗口三件事

这套操作最怕上来就敲命令。同一条vmkfstools -K，我在不同环境里见过两种完全相反的结果，差别不在命令本身，而在盘是什么格式、数据存储是什么文件系统、虚拟机上还挂着什么东西。动手前把这三件事确认掉，比事后找后悔药便宜得多。

2.1 三种磁盘格式：Thin、厚置备延迟归零、厚置备置零

vSphere 里虚拟磁盘的置备方式就三种，回收这件事只对第一种有意义，但另外两种在迁移方案里要当跳板用，所以必须分得清。

磁盘格式	空间怎么分配	删文件后能否回收	转换时的空间占用
精简置备（Thin）	按实际写入量分配	不能自动，需手动回收	等于已用数据量
厚置备延迟归零（Lazy Zeroed）	创建时按配置容量全量分配	不适用	等于配置容量
厚置备置零（Eager Zeroed）	创建时按配置容量分配并写零	不适用	等于配置容量

在 vSphere Client 里看最直接：选中虚拟机 → 编辑设置 → 展开硬盘，看「磁盘置备」那一栏写的是哪个。命令行也能查，前提是虚拟机关机，否则部分字段读不全。

# 登录 ESXi 主机后，查看某个 vmdk 的详细信息 # 输出里重点看 type 字段和 RW 那一行的容量 vmkfstools -D /vmfs/volumes/datastore1/VMName/VMName.vmdk

-D是 dump 的意思，把描述符里的元数据打出来。输出比较长，别被吓到，只盯两处：type是thick还是thin，以及 RW 后面的扇区数——乘 512 就是这块盘的实际大小。如果虚拟机还开着，这个命令读到的部分信息可能滞后，所以盘点阶段我一般挑业务低峰、虚拟机相对安静的时候做。

顺带说一个容易混淆的点：目录里同一个磁盘会有两个文件，VMName.vmdk只有几百字节到几 KB，是描述符；VMName-flat.vmdk才是真正装数据的那个，通常几个 G 到几十 G。回收命令要作用在描述符上，但判断空间有没有降下来，看的是-flat.vmdk的大小。这两个搞反了，后面的排查会一路跑偏。

2.2 VMFS5 为什么不自动回收，VMFS6 又差在哪

VMFS5 不支持自动回收空间，这不是配置没开，是文件系统这一层就没这个机制。guest 操作系统里删掉的文件，到 VMFS5 这里只表现为「这些块的内容不再被引用」，但块本身仍然挂在虚拟磁盘上。Thin 的精简发生在写入那一刻：第一次写到某个块，VMFS 才真正分配。分配出去之后，除非有人主动把这些块「打洞」还回来，否则它们永远算在 VMDK 头上。

后来的 VMFS6 把自动 UNMAP 做成了常规能力，配合支持 UNMAP 的 guest 系统，删除动作能一层层传到存储。这也是为什么同一套操作在不同环境里效果差很多——有人已经跑在 VMFS6 上，删完文件过一阵空间自己就回来了；有人还在 VMFS5，等一年也不会动。Windows Server 2012 R2 这个代际在 VMFS5 上基本指望不上自动回收，老老实实手工做，反而更快。

提示：不确定数据存储是哪个版本，在 vSphere Client 的存储视图里看「VMFS」标签页，会写明 5.x 还是 6.x。这一步别猜。

所以后面两套方法，本质上都是在补 VMFS5 缺的那一环：方法一从 guest 内部把空闲块写成零，再由 ESXi 侧把这些零块识别出来释放；方法二干脆整盘搬迁一次，让复制过程只带走有内容的块。

2.3 停机窗口、工具和一张准备清单

方法一必须关机，这是硬约束，vmkfstools -K在虚拟机运行状态下执行会失败或者干脆没效果。方法二是在线迁移，虚拟机不停，但要求目标存储有足够空间，而且迁移期间 IO 会受影响。两种方法对资源的要求不一样，动手前把清单过一遍。

准备项	方法一要求	方法二要求
虚拟机状态	必须关机	可在线
工具	sdelete64.exe	无，vSphere Client 即可
ESXi SSH	需要临时开启	不需要
数据存储余量	能容纳 VMDK 膨胀后的峰值	目标存储能放下整块配置容量
快照	必须先删除	必须先删除
耗时量级	与空闲空间大小正相关	与磁盘配置容量和存储性能相关

清单里我特意把快照单列一行，因为它是这套流程里最常见的隐形拦路虎：虚拟机挂着快照时，写入会落到快照增量盘上，回收命令作用不到原始数据，跑完一看空间没变，白等几个小时。回收前先把快照删掉或者合并掉，这一步没有捷径。

工具这边，SDelete 是微软 Sysinternals 套件里的一个命令行实用程序，作用是清除逻辑磁盘上的空闲空间。从微软 Sysinternals 官方下载页拿到压缩包，解压后 64 位系统用sdelete64.exe，32 位系统用sdelete.exe。ESXi 侧的 SSH 默认是关的，需要在主机 → 服务里临时启用，用完记得关回去。

3. 方法一实操：sdelete64 清零加 vmkfstools -K 回收全流程

这套方法分两段，前半段在虚拟机内部做，把空闲块写成零；后半段在 ESXi 主机上做，把这些零块还给数据存储。两段之间必须关机，顺序不能颠倒。

3.1 把 sdelete64.exe 放进虚拟机并确认盘符

下载下来的 Sysinternals 包解压后文件不少，只挑sdelete64.exe一个就够。我的习惯是直接拷到 C 盘根目录，路径短，CMD 里不用来回切目录，也避免了路径里带空格导致的引号问题。

拷贝完先裸跑一次，确认文件本身没被拦下来：

:: 以管理员身份打开 CMD，直接执行不带参数，会打印用法说明 C:\> sdelete64.exe

能打出参数列表就说明可执行。这一步看着多余，实际上能挡掉两类问题：一是杀毒软件把工具静默隔离了，执行时提示找不到文件；二是拿到的是 32 位版本，在 64 位系统上虽然也能跑，但处理大容量磁盘时效率差一截。

确认盘符也很关键。原文的场景是一台单分区的虚拟机，C:就是全部。多分区的机器要逐个分区处理，数据盘上如果有大量删除过的文件，同样会撑大 VMDK，只清 C 盘等于只回收了一半。

:: 看一眼当前机器有哪些分区，确认要清理的盘符 C:\> wmic logicaldisk get caption,freespace,size

freespace是空闲字节数，size是总容量。两者一减就是已用空间，和 vSphere 里看到的 VMDK 大小对一下，差值有多大，回收的收益就有多大。

3.2 sdelete64.exe -z C: 清零空闲空间

核心命令只有一条：

:: -z 表示清零空闲空间，这是回收能生效的前提 C:\> sdelete64.exe -z C: :: 如果希望减少无谓的多轮写入，可以显式指定覆盖次数为 1 C:\> sdelete64.exe -z -p 1 C:

参数逐个说清楚。-z是 zero free space，把 NTFS 认为空闲的簇全部写成 0，这是这条命令存在的唯一理由，不加-z就变成清理文件了，跟回收没关系。-p是覆盖次数（passes），默认就是 1，写不写差别不大，只有在有安全擦除要求的场景才需要往上调，调到 3 以上会让整个流程慢好几倍。-s是递归子目录，清理文件时用，-z场景下不需要。-q是安静模式，去掉进度输出，批处理里用得上，手工操作反而希望看到进度。-nobanner去掉启动横幅，纯粹是让日志干净一点。

执行之后会看到一条进度条在走，速度取决于空闲空间大小和存储性能。几十 G 的空闲空间跑一两个小时不稀奇，机械盘上更久。这时候别急着开第二个窗口去 vSphere 里看容量，看了会心慌。

注意：清零过程中 VMDK 会明显膨胀，极端情况下会涨到接近虚拟磁盘的配置容量。这是预期内的中间状态——那些原本「空闲」的块现在被写进了零，VMFS 认为它们有内容，自然就分配出去了。等下一步vmkfstools -K跑完，这些块才会被真正释放。中途看见数据存储快满了先别停，先确认剩余空间能不能撑到回收结束。

跑完之后，虚拟机关机。关机前顺手确认一下没有挂载的 ISO、没有正在写的日志，避免关机卡在某个进程上。

3.3 SSH 登录 ESXi，定位到具体的 -flat.vmdk

关机之后换到 ESXi 侧。用 SSH 登录到虚拟机所在的那台主机：

# 地址换成你自己的 ESXi 管理地址，这里只是示例 ssh root@192.0.2.10

登录后先看数据存储挂在哪儿。ESXi 的/vmfs/volumes/下面每个数据存储会出现两条记录：一条是 UUID 命名的真实目录，一条是好记的名字做的软链接，指向同一个地方。进哪个都行，用友好名更省事。

# 列出所有数据存储，确认目标存储的挂载名 ls -l /vmfs/volumes/ # 进入虚拟机目录，路径按实际情况替换 cd /vmfs/volumes/datastore1/VMName/ # 看清楚目录里有哪些 vmdk，别急着执行通配符 ls -lh *.vmdk

ls -lh的输出会同时列出描述符和-flat.vmdk。真正占空间的是后者，回收前后对比的就是它的大小。目录里如果有多块磁盘，比如系统盘加数据盘，*.vmdk会把它们全部匹配上。

原文给的命令是vmkfstools -K *.vmdk，通配符的好处是一条命令处理全部磁盘，省事。但我一般会先ls看清楚再逐个指名道姓地执行，原因是：如果目录里混着一块厚置备的磁盘，-K对它无效，可能报错中断，前面的活就白干了；另外多块盘逐个跑，进度和耗时都更好估算，出问题也容易定位是哪一块。

3.4 vmkfstools -K 执行回收，盯住进度和剩余空间

# -K 的作用是对 thin 磁盘打洞，把内容全零的块还给数据存储 # 参数是 vmdk 的描述符文件，不是 -flat.vmdk vmkfstools -K /vmfs/volumes/datastore1/VMName/VMName.vmdk

-K这个参数从 ESXi 5.x 之后就有，专门用于 thin 磁盘的空间回收。它做的事情可以理解为扫描整块虚拟磁盘，把内容全是零的块标记为「未分配」，从 VMDK 的占用里扣掉。所以前一步 SDelete 不是可有可无的准备工作，它是让「空闲块」变成「全零块」的唯一手段，没有这一步，-K扫完会发现所有块都非零，什么都回收不了。

命令回车后不会有花哨的进度条，屏幕上可能长时间没动静，这是正常的。想确认它真的在干活，另开一个 SSH 窗口盯两个数字：

# 每 10 秒刷新一次，看 flat 文件在缩、数据存储剩余在涨 watch -n 10 'ls -lh /vmfs/volumes/datastore1/VMName/VMName-flat.vmdk; df -h /vmfs/volumes/datastore1'

ls -lh看的是单个文件大小变化，df -h看的是整个数据存储的剩余空间。两个数字应该同步往好的方向走：flat 文件变小，剩余空间变大。如果盯了十几分钟两个数字纹丝不动，那基本可以判定这次回收没生效，别再等了，跳到第 5 章对照排查。

耗时没有固定值。同样 30G 的回收量，全闪存储上十几分钟，老机械盘阵列上跑三四个小时也遇到过。中断了也不要紧，-K不是原子操作，已经打洞的部分不会回滚，重新执行会从剩下的部分继续，不会把前面的成果抹掉。

4. 方法二实操：Storage vMotion 转厚置备再回迁 Thin

方法一要求停机，碰上不能停的业务就得换路子。Storage vMotion 的思路不一样：整盘搬到另一个数据存储，迁移过程中重新组织数据，落在目标端的文件自然就是紧凑的。这套操作全程在线，虚拟机不用关机。

4.1 迁移前的容量预算与目标存储检查

这一步最容易翻车的地方是容量算法。很多人拿 guest 里的已用空间去估目标存储需要多少，结果迁移跑到一半报空间不足。原因很简单：中间那一跳选的是厚置备，厚置备按虚拟磁盘的配置容量分配，不是按已用数据量分配。

虚拟磁盘配置容量	guest 内实际已用	转厚置备后目标存储占用	回迁 Thin 后占用
100G	30G	约 100G	约 30G 上下

一百 G 的盘只用了三十 G，中间那一跳照样要占掉一百 G。预算按配置容量算，别按已用算，这是血泪经验。

动手前先确认目标存储的剩余空间：

# 在 ESXi 主机上查看各数据存储的容量和剩余 df -h | grep vmfs # 单独看某一个数据存储的细节 vmkfstools -Ph /vmfs/volumes/datastore2

df -h的输出里重点看 Use% 那一列，剩余空间要大于虚拟磁盘的配置容量，再留出百分之十左右的余量给迁移过程中的临时开销。vmkfstools -Ph会额外打出块大小、支持的文件类型这些信息，目标存储如果是不同版本的 VMFS，这一步能提前发现不兼容。

还有一点常被忽略：虚拟机如果有快照，迁移时快照文件也会一起搬，实际占用会比预算多。所以跟前一套方法一样，先把快照清干净再动手。

4.2 右键迁移：更改数据存储与厚置备延迟归零

操作路径在 vSphere Client 里，步骤不多，但每一步的选择都会影响最后能不能瘦下来。

在清单里选中目标虚拟机，右键 → 迁移。
迁移类型选「仅更改存储」，不要选「更改计算资源」，后者会连带触发一次计算资源的重新放置，没必要。
选择目标数据存储，注意看容量条，别选到快满的那个。
关键一步：虚拟磁盘格式选「厚置备延迟归零」。
确认摘要页的信息，点完成，然后等。

为什么中间这一跳不直接选 Thin？因为源盘已经是 Thin 了，直接从 Thin 迁到 Thin，复制过程能带走的只有已分配的块，那些「已分配但内容全零」的块还是会被当成有效数据搬过去，瘦身效果打折。先落成厚置备延迟归零，等于强制把整块盘按配置容量铺开，再回迁 Thin 的时候，全零的块会被识别出来跳过，落回目标存储的就只剩真正有内容的部分。

迁移开始后，任务栏里能看到进度百分比。这个百分比不是线性的，前期在传数据，后期在收尾，卡在 90% 很久是常态。耗时取决于配置容量和存储带宽，一百 G 的盘在两台性能正常的存储之间挪动，半小时到两小时都算正常范围。

期间虚拟机一直在线，但磁盘 IO 会有可感知的抖动，跑数据库的机器建议避开业务高峰。迁移完成后，虚拟机会落在新存储上，磁盘格式变成厚置备延迟归零，此时 vSphere 里看到的占用就是配置容量。

4.3 想回 Thin 就再来一次 vMotion，以及它的代价

如果目标就是彻底摆脱 Thin 的空间虚高问题，可以让虚拟机以厚置备的形式留在新存储上，简单直接。但如果存储容量紧张，还是得回到 Thin，那就再做一次 Storage vMotion，把虚拟机迁回原来的数据存储，磁盘格式这次选「Thin」。

第一次迁移：源存储（Thin） → 目标存储（厚置备延迟归零） 作用：把整盘铺开，让零块显形 第二次迁移：目标存储（厚置备延迟归零） → 源存储（Thin） 作用：复制时跳过全零块，落回 Thin 时只占实际数据量

两次迁移加起来是两次全量拷贝，IO 压力和耗时都是单次的两倍。这是这套方法的主要代价，换来的是全程不停机。第一次迁移把数据摊平，第二次迁移在复制时把全零块筛掉，最终落在源存储上的 VMDK 就是压缩过的。

有个细节要提醒：第二次迁移前，确认源存储的剩余空间够放回迁后的精简磁盘。虽然理论上回迁后占用会大幅下降，但迁移过程中目标端是边写边算的，瞬时占用可能比预期高一点，留出余量更稳妥。

还有一种更省事的做法，有同行试过直接从 Thin 迁到另一存储的 Thin，一次搞定。这条路在数据分布比较规整的情况下也能瘦下来，因为复制过程同样会跳过未被引用的块。区别在于厚置备那一跳会把「已分配但内容全零」的块也识别出来，瘦得更彻底。两种做法都能跑通，看你对回收效果的预期。

5. 避坑与排查：五条回收翻车记录，按现象原因解决拆开

这套流程看起来命令不多，但每一步都有能让人卡住半天的地方。下面五条是我在实际环境里反复遇到的，按「现象 → 原因 → 解决」记，照着对号入座基本能定位。

5.1 清零阶段的两个坑

现象一：SDelete 跑完之后，VMDK 不降反涨，从 36G 涨到接近 100G，数据存储直接报警。

原因：sdelete64.exe -z做的是把空闲簇写成零，这些块在 guest 里是空闲的，但写零这个动作让 VMFS 认为它们有内容，于是实打实地分配了出去。磁盘越空，涨得越狠，一块一百 G 的盘如果只用了三十 G，清零后 VMDK 会逼近一百 G。这是必经的中间态，不是命令用错了。

解决：先确认数据存储剩余空间能不能撑到vmkfstools -K跑完。撑得住就继续往下走，跑完自然回落；撑不住就换方法二，或者临时扩一下数据存储再回来做。以后再做同类操作，我一般会提前看一眼剩余空间，宁可先扩再清，也不在中途卡住。

现象二：SDelete 跑了几分钟就退出，提示「Access is denied」，或者进度条压根没出现。

原因：CMD 不是以管理员权限打开的。清零空闲空间需要直接操作磁盘扇区，普通权限拿不到这个句柄。另一个可能是杀毒软件实时防护把这个行为判定成可疑写入，直接掐掉了进程。

解决：开始菜单里搜 CMD，右键选「以管理员身份运行」，标题栏上会带「管理员」字样再执行。杀毒软件这边，临时把这台机器的实时防护关掉，或者把sdelete64.exe加进白名单，跑完再恢复。企业环境里如果装了统一的安全策略，提前跟管策略的人打个招呼，别等跑到一半被拦。

5.2 回收与迁移阶段的三个坑

现象三：vmkfstools -K回车后立刻返回，什么输出都没有，空间一点没变。

原因：大概率踩了三个雷之一。虚拟机没关机，-K对运行中的虚拟机无效；虚拟机挂着快照，写入落在增量盘上，原始 VMDK 的块没变化；磁盘格式根本不是 Thin，厚置备的块本来就是全量分配，没有洞可打。

解决：按顺序排除。先vim-cmd vmsvc/power.getstate <vmid>确认虚拟机确实是关机状态，注意「已挂起」不算关机；再在快照管理器里看有没有快照，有就删掉或合并；最后用vmkfstools -D确认这块盘是 thin。三个条件缺一不可。还有一种情况是命令里写成了-flat.vmdk，-K要的是描述符那个文件，写错了同样静默失败。

现象四：Storage vMotion 跑到一半失败，任务里提示存储空间不足，虚拟机留在原处。

原因：容量按 guest 已用空间算的，没按虚拟磁盘配置容量算。中间那一跳选的是厚置备延迟归零，目标端要按配置容量全量分配，一百 G 的盘哪怕只用了三十 G，也要一百 G 的空间才放得下。

解决：先算清楚vmkfstools -D里读到的配置容量，再去目标存储里对剩余空间，不够就先清理或换一个存储。失败的任务不会破坏虚拟机，删掉重来即可，但要注意重试前确认目标存储上有没有留下半截文件，有的话手动清掉再开始。

现象五：两次 vMotion 都跑完了，虚拟机回到 Thin，可空间只降了一点点，远没到预期。

原因：guest 里从来没有做过清零，那些删掉的文件对应的块内容还是旧的随机数据，不是零。迁移过程只跳过「内容全零」的块，非零的块照样搬过去，自然瘦不下来。另一个可能是第二次迁移时格式选项没选对，落回了厚置备。

解决：回 guest 里补做一次sdelete64.exe -z C:，再走一遍迁移。如果确认清零做过，就去检查第二次迁移的格式选项，vSphere Client 在迁移向导的最后一步会列出每块盘的格式，这一页别一路回车过去。还有一种情况是虚拟机里存在定期任务，回收完马上又写满了，这种得从业务侧解决，回收本身治不了。

提示：每次做完回收，顺手把df -h的输出和ls -lh *.vmdk的结果各存一份。过一周再对比，如果空间又掉回去了，说明有持续写入的源头没找到，早发现比晚了再排查省事。

6. 装完怎么验证：四个检查点确认空间真的回来了

回收跑完不等于结束，这套操作最后一定要落到验证上，否则过几天发现空间没变，前面几个小时的等待就成了玄学。我一般按四个检查点过一遍，从内到外对数字。

检查点	在哪看	命令或位置	期望结果
一、guest 内使用量	虚拟机内部	`wmic logicaldisk get caption,freespace,size`	与回收前一致，说明数据没丢
二、VMDK 实际大小	ESXi 主机	`ls -lh VMName-flat.vmdk`	明显小于回收前
三、数据存储剩余	ESXi 主机	`df -h /vmfs/volumes/datastore1`	剩余空间增加，增加量接近差值
四、vSphere 视图	vSphere Client	存储 → 文件 → 虚拟机目录	与命令行数字对得上