VMFS5 Thin磁盘回收：SDelete与vmkfstools -K实战

简介：这份 docx 文档面向使用 VMware 虚拟化平台、需要处理 Thin 精简卷空间占用的运维与实验人员，围绕 vmfs5 环境下精简磁盘无法自动回收空间的问题整理解决方案，适合具备基础虚拟化操作经验、希望补齐容量治理思路的学习者参考。包内共 1 个 docx 文件，约 408KB，以图文记录形式组织，便于在实验环境或日常维护中按需查阅。内容涵盖 SDelete 清理空闲空间后配合 vmkfstools 回收，以及通过 Storage VMotion 更改磁盘格式实现在线释放空间两条路径，并对停机要求、格式转换与回收效果验证作出说明，兼顾原理理解与方案取舍。已有 2021 人学习，可作为精简卷容量治理、空间异常排查和存储迁移练习的参考材料，帮助读者判断 Thin 磁盘空间回收的适用场景与注意事项。

1. 36.7G 的 vmdk 只涨不降：Thin 精简磁盘回收不是删文件就完事

Thin 精简置备在 VMware 环境里太常见了，尤其是 Windows Server 2012 R2 这类老系统盘，创建时选了 Thin，后面删日志、删安装包，Guest 里看只剩 27.8G，VMDK 却还占 36.7G。VMFS5 不会自动把 Guest 的空闲块还给存储，删文件只是文件系统内部记账，vmdk 该多大还多大。装不好会怎样？轻则存储告警，重则迁移时目标空间不够直接卡住。这套回收流程适合手里有 ESXi + VMFS5、虚拟机磁盘格式为 Thin 的运维和开发，方法一需要停机，方法二可以在线迁移，选哪条先看窗口。

2. 环境盘点：ESXi 与 VMFS5 下 Thin 磁盘回收的版本边界

先别急着敲命令。Thin 回收失败多半不是命令写错，而是把 VMFS5 当成 VMFS6 用，或者没看清 vmdk 格式。项目正文记录的环境是 Windows Server 2012 R2、ESXi 主机、VMFS5 数据存储、Thin 磁盘。这个组合有一个硬限制：VMFS5 不支持自动 unmap，Guest 里删文件不会触发底层块回收，必须手动做。VMFS6 的自动回收策略不一样，拿 VMFS6 的经验套 VMFS5，很容易以为跑完 SDelete 就完事，结果 vmdk 一点没瘦。我一般会先把版本、格式、快照三件事查清楚，再决定走哪条路径。

2.1 先确认三件事：ESXi 版本、VMFS 版本、虚拟机磁盘格式

登录 ESXi Shell 后，先看数据存储的文件系统版本，不要只看容量。VMFS5 和 VMFS6 在回收行为上不是一回事，命令一样，效果可能完全不同。

# 查看数据存储挂载点、容量和空闲空间 esxcli storage filesystem list # 查看 VMFS 数据存储的版本和 extent 信息 esxcli storage vmfs extent list

esxcli storage filesystem list用来看挂载点、总容量和剩余空间，确认虚拟机到底落在哪个 datastore。esxcli storage vmfs extent list用来看 VMFS 版本，输出里如果是 VMFS-5，就按手动回收走；如果是 VMFS-6，先确认自动 unmap 有没有开启，别直接套下面的停机流程。常见做法是先记录回收前的ls -lh结果，后面验证有对照。

再看 vmdk 格式。Thin 磁盘的描述文件里会有thinProvisioned标记，直接 cat 比在客户端里猜更稳。

# 进入虚拟机目录，路径按实际 datastore 和虚拟机名替换 cd /vmfs/volumes/datastore1/Windows2012R2 # 查看 vmdk 描述文件里的精简置备标记 cat Windows2012R2.vmdk | grep -E "thinProvisioned|createType"

ddb.thinProvisioned = "1"表示这块盘是 Thin；如果看到的是0或者没有这个标记，先别跑vmkfstools -K，那是对牛弹琴。createType也能辅助判断，vmfsSparse通常对应精简格式。这个检查不花时间，但能省掉后面半小时的无效等待。

2.2 两种回收路径的适用场景与前置条件

项目正文给了两条路：方法一是 Guest 内 SDelete 清零空闲空间，关机后在 ESXi 层用vmkfstools -K回收；方法二是 Storage vMotion 迁移时重写磁盘，把未使用块丢掉。两条路不是谁更高级，而是窗口和存储余量不同。

方法一适合维护窗口明确的单机回收，命令少，但必须停机。方法二适合在线窗口，前提是目标存储有足够空间放厚置备延迟归零的磁盘。这里有个容易误判的点：厚置备延迟归零不是按 Guest 实际使用量算，而是按虚拟磁盘配置容量算。磁盘配了 100G，实际只用 27.8G，目标存储也要准备 100G 左右的余量，不然兼容性检查就会卡住。

2.3 工具清单与文件放置位置

这套流程用到的工具不多，但位置放错会多绕一圈。SDelete 不要放在网络共享盘里跑，ESXi 端不需要上传vmkfstools，它是 Shell 自带的。

SDelete 从项目正文记录的微软 Sysinternals 页面取，下载后只拷sdelete64.exe就够用。放到C:\Tools\是为了命令短、路径固定，后面写批处理也不容易错。ESXi 端只需要开 SSH，用现有账号登录，vmkfstools直接在/bin里，不用额外装。

2.4 停机窗口和备份怎么做

方法一必须关机，窗口不要只按“跑命令的几分钟”估。SDelete 清零空闲空间的时间取决于 Guest 空闲块大小和存储性能，vmkfstools -K的时间取决于 vmdk 大小和存储负载。老存储上跑 36.7G 的 vmdk，可能十几分钟，也可能更久，窗口留足。

备份别省。Thin 回收不是无风险操作，尤其是用通配符处理多个 vmdk 的时候，选错文件会很难受。常见做法是回收前做一次虚拟机备份，或者在存储层留一份快照。但注意，虚拟机快照要在回收前删掉或合并，快照 delta 文件会干扰vmkfstools -K的判断。vSphere Client 里打开快照管理器看一眼，有快照先处理，再关机。

注意：VMFS5 下手动回收不会自动发生，SDelete 只是第一步，ESXi 层的vmkfstools -K才是真正把块还给存储的动作。两步顺序不能反。

3. 方法一落地：SDelete64 清理 Windows Server 2012 R2 空闲空间与 vmkfstools -K 回收 vmdk

这条路径分两段：Guest 里用 SDelete 把空闲块写成零，让 ESXi 知道哪些块没用了；然后在 ESXi 层用vmkfstools -K把这些零块打洞回收。顺序不能反，虚拟机不关机也不要跑-K。我一般会先在 Guest 里确认盘符和空闲空间，再关机进 ESXi，避免开着机白跑一遍。

3.1 在 Guest OS 里用 SDelete64 清零空闲空间

先把sdelete64.exe放到C:\Tools\，用管理员权限打开 CMD。不要用普通权限，也不要对网络盘执行。项目正文里的环境是 Windows Server 2012 R2，测试盘只有一个分区，所以命令直接对 C 盘跑；如果有多块数据盘，需要逐个卷处理。

:: 进入工具目录，确认 sdelete64.exe 在当前路径 cd /d C:\Tools :: 先看帮助，确认当前版本支持 -z 参数 sdelete64.exe -h :: 清零 C 盘空闲空间，-z 表示 zero free space sdelete64.exe -z C:

-z的作用是清零空闲空间，不是删除文件，也不是扩容。C:是目标卷，不要写成C:\，也不要对网络映射盘跑。执行后会出现进度条，时间取决于空闲空间大小；SSD 上还要评估写放大，别在业务高峰做。跑完 Guest 里可用空间不会变，这是正常的，别以为白跑，真正的空间释放发生在 ESXi 层。

如果虚拟机有多个分区，常见做法是每个需要回收的卷都跑一遍，比如sdelete64.exe -z D:。但不要对光驱、恢复分区乱跑。项目正文只记录了单分区测试环境，多分区场景先确认盘符，再逐条执行。

3.2 关机后登录 ESXi Shell，找到正确的 vmdk 路径

SDelete 跑完，把虚拟机关机。注意是关机，不是挂起，也不是重启。然后在 vSphere Client 里确认 SSH 服务已开启，用 SSH 登录虚拟机所在的 ESXi 主机。

# 查看数据存储挂载点，确认虚拟机在哪个 datastore esxcli storage filesystem list # 进入虚拟机目录，路径按实际 datastore 和虚拟机名替换 cd /vmfs/volumes/datastore1/Windows2012R2 # 列出 vmdk，先看文件名和大小，别急着用通配符 ls -lh *.vmdk

esxcli storage filesystem list用来看 datastore 挂载点，别凭记忆写路径。cd进入虚拟机目录后，ls -lh *.vmdk先列文件，重点看主数据盘和有没有-delta.vmdk、-000001.vmdk这类快照文件。有快照文件先回 vSphere Client 删快照或合并，不要直接对 delta 文件跑回收。ESXi Shell 路径大小写敏感，虚拟机名和 datastore 名按实际输出抄，别手打。

3.3 执行 vmkfstools -K 并观察回收进度

确认虚拟机关机、快照已处理、vmdk 是 Thin 之后，再执行回收。项目正文里写的是vmkfstools –K *.vmdk，实际落地时我不建议一把梭，先把主数据盘文件名列清楚，逐个执行更稳。

# 对指定 vmdk 执行 punch zero，虚拟机必须已关机 vmkfstools -K Windows2012R2.vmdk # 如果有多个数据盘，按实际文件名逐个执行 vmkfstools -K Windows2012R2_1.vmdk

-K是 punch zero，用来回收 Thin 磁盘里未使用的块；执行时会显示进度百分比，等待完成。不要对描述文件、快照 delta 文件执行。文件名必须和ls -lh里看到的主数据盘一致。如果虚拟机有多块盘，逐条跑，别用*.vmdk把不该处理的文件带进去。回收时间取决于 vmdk 大小和存储负载，进度条走得慢不代表卡死，先等。

如果确认目录里只有主数据盘，也可以写明确文件名的循环，但不要把通配符写进循环：

# 只对明确列出的主数据盘循环，避免误伤快照文件 for f in Windows2012R2.vmdk Windows2012R2_1.vmdk; do vmkfstools -K "$f" done

循环里的文件名是写死的，不是*.vmdk。这样即使目录里后面多出 delta 文件，也不会被卷进去。跑完一块再跑下一块，观察每块的进度和报错。

3.4 回收后的磁盘格式与空间核对

回收完成后，不要只看进度条结束。先看 vmdk 实际占用有没有下降，再确认格式还是不是 Thin。

# 看 vmdk 实际占用是否下降 ls -lh Windows2012R2.vmdk # 确认磁盘格式仍是 Thin cat Windows2012R2.vmdk | grep thinProvisioned

ls -lh看文件大小，回收后应该从 36.7G 往 27.8G 附近靠，具体数值受文件系统块和 vmdk 元数据影响，不会一模一样。thinProvisioned = "1"表示还是 Thin；如果变成 0，检查是不是中途做过格式转换。确认无误后开机，进系统看业务是否正常。Guest 里可用空间不会因为回收变大，回收的是存储侧占用，不是 Guest 分区容量。

提示：方法一的核心是“先清零、再关机、后打洞”。SDelete 跑错卷、虚拟机没关机、快照没删，都会让vmkfstools -K的效果打折扣。

4. 方法二落地：Storage vMotion 在线迁移与厚置备延迟归零格式转换

如果维护窗口不够停机，就走 Storage vMotion。原理不复杂：迁移时虚拟磁盘会被重写，未使用块不复制，落到目标存储后空间就释放了。项目正文给的做法是先迁到目标存储，格式选厚置备延迟归零；如果还想用 Thin，再迁回原存储，格式选 Thin。这条路径能在线做，但对目标存储余量要求高，别只看 Guest 实际使用量。

4.1 在线迁移前先算目标存储余量

Storage vMotion 一般在 vCenter 里操作，迁移前先看目标数据存储剩多少。用 vSphere Client 看也行，习惯命令行的可以用 PowerCLI 查。

# 连接 vCenter，地址和账号按环境替换 Connect-VIServer -Server vcenter.example.local # 查看目标数据存储容量和剩余空间，单位 GB Get-Datastore -Name "DS-Target" | Select-Object Name,CapacityGB,FreeSpaceGB

CapacityGB是总容量，FreeSpaceGB是剩余空间。厚置备延迟归零按虚拟磁盘配置容量分配，不是按 Guest 实际使用量。磁盘配了 100G、实际只用 27.8G，目标存储也要准备 100G 左右的余量，再加上迁移过程中的开销。余量不够时，兼容性检查就会报错，别等到迁移跑到一半才停。

4.2 更改数据存储并选厚置备延迟归零

在 vSphere Client 里选中虚拟机，右键迁移，选择“仅更改存储”。目标数据存储选有足够空间的那个，虚拟磁盘格式选“厚置备延迟归零”。这个格式会在迁移时把未使用块丢掉，迁移完成后 vmdk 按容量分配，但不再保留原来的空洞。

步骤上注意三点：第一，迁移类型选“仅更改存储”，不要选“更改主机和存储”，除非你确实要换主机；第二，目标存储的余量按配置容量算；第三，提交前看兼容性检查，有警告先处理。迁移期间虚拟机可以在线，但会占存储带宽，业务高峰尽量避开。

迁移完成后，vmdk 格式会变成厚置备延迟归零，原来 Thin 的空洞被丢弃，存储空间释放。这时候如果业务只要求空间回收，已经达到目的。但如果你还想继续用 Thin，别停在这里。

4.3 迁回原存储时切回 Thin 格式

项目正文给的做法是再迁回原存储，格式选 Thin。这样来回一次，空间释放了，格式也回到精简置备。操作还是右键迁移、仅更改存储，目标选原数据存储，格式选 Thin。

迁回 Thin 时，目标存储要有空间放精简后的 vmdk，按实际使用量估算。来回迁移需要两次带宽和时间，窗口要留够。迁回完成后，用ls -lh和cat vmdk确认格式和大小，别只看客户端里的显示。

4.4 在线路径的停机窗口与风险控制

Storage vMotion 能在线做，不等于可以随便做。迁移期间存储 IO 会升高，老存储上可能影响业务；快照多、磁盘大的虚拟机，迁移时间会更长。常见做法是先在测试虚拟机走一遍，记录迁移耗时和目标存储余量，再排生产窗口。

回滚方面，Storage vMotion 不像快照那样一键回退，迁移前备份还是要做。如果迁回 Thin 时目标空间不够，虚拟机可能停在厚置备格式，存储反而更紧。所以第一次迁移前就把“目标存储够不够、要不要迁回”算清楚，别等格式变了再找后悔药。

注意：厚置备延迟归零是按磁盘容量占空间，不是按 Guest 实际使用量。目标存储余量不够时，在线迁移也会失败。

5. 避坑排查：Thin 回收里最容易翻车的五个现场

这一章按现象、原因、解决来记。Thin 回收不是玄学，但几个细节没确认，命令跑完也看不到效果。下面五条是我在类似环境里踩过的，别等存储告警才翻。

5.1 现象：vmkfstools -K 跑完，vmdk 大小没变

现象很直接：进度条走完了，ls -lh一看还是 36.7G，Guest 里也看不出变化。原因通常有四个：虚拟机没关机、有快照没删、vmdk 不是 Thin、SDelete 没跑或跑错卷。vmkfstools -K对开机状态的虚拟机不会按预期回收，快照 delta 也会干扰主盘判断。

解决顺序是先查格式和快照，再查关机状态。cat vmdk | grep thinProvisioned看是不是 Thin；vSphere Client 快照管理器看有没有快照；确认虚拟机关机，不是挂起。SDelete 那边确认-z跑的是实际数据卷，不是只跑了系统盘却漏了数据盘。四项都确认后再跑一次，别在没关机的时候反复试。

5.2 现象：SDelete 跑完 Guest 空间没增加，以为白跑

SDelete 跑完，Guest 里可用空间没变，这是最容易误判的一条。sdelete64.exe -z C:做的是清零空闲空间，不是删除文件，也不是扩容。它让 ESXi 知道哪些块是空闲的，真正的回收动作在vmkfstools -K。

解决方法是把验证位置换到 ESXi 层。Guest 里看可用空间没意义，去 ESXi 目录看 vmdk 大小，或者看数据存储剩余空间。跑完 SDelete 后直接关机进 ESXi，别在 Guest 里反复跑第二遍。多分区环境要逐个卷跑，只跑 C 盘、不跑数据盘，数据盘对应的 vmdk 也不会瘦。

5.3 现象：用 *.vmdk 一把梭，回收后虚拟机起不来

项目正文里写的是vmkfstools –K *.vmdk，但实际目录里可能有-flat.vmdk、-delta.vmdk、-000001.vmdk。通配符会把不该处理的文件带进去，轻则报错，重则虚拟机起不来。这种翻车现场处理起来很麻烦，尤其是有快照的时候。

解决方法是先ls -lh *.vmdk列文件，确认哪个是主数据盘，再逐个执行。有快照先删快照或合并，不要对 delta 文件跑-K。循环也要写明确文件名，不要图省事写通配符。备份先做，别把回收当成无风险操作。

5.4 现象：Storage vMotion 兼容性检查失败，提示目标空间不足

在线迁移时选了厚置备延迟归零，兼容性检查直接报目标空间不足。原因不是 Guest 实际用了多少，而是厚置备按虚拟磁盘配置容量分配。磁盘配了 100G，目标存储只剩 50G，就算 Guest 里只用了 27.8G，也过不去。

解决方法是迁移前先算容量，用 vSphere Client 或 PowerCLI 看目标存储剩余空间，按配置容量加开销估算。余量不够就清目标存储，或者改走方法一停机回收。别在兼容性检查报错后反复重试，先看目标存储余量。

5.5 现象：回收后格式从 Thin 变成厚置备，存储反而更紧

这条是 Storage vMotion 路径的常见坑：迁到厚置备延迟归零后空间释放了，但格式变厚，存储分配变大。如果没迁回 Thin，后续再扩容或迁移，空间会更紧。看起来回收成功，实际格式变了。

解决方法是确认需求：只要释放空间，厚置备延迟归零可以接受；还要继续用 Thin，就再迁回原存储，格式选 Thin。迁回前确认目标存储余量，迁回后用cat vmdk看thinProvisioned是否回到 1。别只看客户端里的“已用空间”，格式字段也要看。

6. 装完验证：用三条命令和一张对照表确认 vmdk 真的瘦下来

回收完别只看进度条。先看 vmdk 实际大小，再看格式，最后看 Guest 业务。验证动作放在 ESXi Shell 里做，比在客户端里点来点去更直接。

# 登录 ESXi，进入虚拟机目录 cd /vmfs/volumes/datastore1/Windows2012R2 # 看 vmdk 占用，单位人类可读 ls -lh Windows2012R2.vmdk # 确认磁盘格式仍是 Thin cat Windows2012R2.vmdk | grep -E "thinProvisioned|createType"

ls -lh看文件大小，回收后应该从 36.7G 往 27.8G 附近靠。thinProvisioned = "1"表示还是 Thin；如果走了 Storage vMotion 厚置备中转，这里可能是 0，需要再迁回 Thin。createType辅助判断格式，别只盯一个字段。

最后开机进系统，看业务日志和磁盘告警。Guest 里可用空间不会因为回收变大，验证的是存储侧 vmdk 占用和格式。从那以后我每次做 Thin 回收，都先删快照、关机、备份，再跑vmkfstools -K，宁可多花十分钟确认，也不想在存储告警时找后悔药。这份 docx 把两种路径的命令顺序、格式选择和截图位置都记在一起，复现时按“方法一/方法二”找对应段落就行。希望帮到你。

本文还有配套的精品资源，点击获取