ESXi精简卷空间回收实战：sdelete与Storage vMotion两种方法

简介：这份文档面向 VMware 虚拟化运维人员与存储管理员，聚焦 ESXi 环境下精简磁盘（Thin）空间无法自动释放的常见痛点，给出可落地的回收思路与操作参考。内容围绕 vmfs5 文件系统不支持自动回收空间的机制展开，分别梳理 SDelete 清理空闲空间配合 vmkfstools 回收，以及通过 Storage VMotion 在线迁移释放空间两条路径，并说明 Thin 格式的优缺点与精简卷管理要点。资源包共 1 个 docx 文件，约 408KB，以图文步骤形式记录关键命令与执行过程，便于对照排查。目前已有 2015 人学习下载，适合需要处理 VMDK 占用虚高、精简卷空间浪费问题的中高级运维人员参考，可帮助快速理解回收原理、选择停机或在线方案并完成空间释放。

1. 精简卷空间回收：从 36.7G 的 VMDK 说起

接手一台 Server 2012 R2 虚拟机时，我盯着数据存储面板愣了几秒：客户明明说磁盘里只用了 27.8G，可那个 VMDK 文件硬是占着 36.7G 不放。删掉的文件、清空的回收站，在 Thin 磁盘上就像没发生过一样，空间死活不吐出来。这不是玄学，是 vmfs5 文件系统压根不支持自动回收——精简卷的「精简」只体现在写入时按需分配，删除时它可不管。如果你也在用 ESXi 配 Thin 磁盘，迟早会撞上这个坑：存储池告急，虚拟机却还在虚占空间。这篇笔记就按我实际操作的顺序，把两种回收方法从环境准备到验证跑通完整走一遍，顺带把中间翻过的车也一并记下来。

2. 回收前的环境确认：别急着敲命令

2.1 先搞清楚你的磁盘到底是不是 Thin

动手之前，必须确认两件事：虚拟磁盘格式是不是 Thin，以及 ESXi 主机版本和 VMFS 版本。很多人一上来就找 sdelete，结果发现自己的盘是厚置备，白忙一场。登录 ESXi 主机后，用 SSH 连上去，执行：

# 查看虚拟机目录下 vmdk 文件的详细信息 vmkfstools -D /vmfs/volumes/你的数据存储名/虚拟机名/虚拟机名.vmdk

输出里重点看Thin或Eagerly Zeroed Thick、Lazy Zeroed Thick这几个关键词。如果是 Thin，才有回收的必要。另外确认 VMFS 版本：

# 查看数据存储的文件系统类型 vmkfstools -P /vmfs/volumes/你的数据存储名

输出中FileSystemType显示VMFS-5就对了。VMFS-6 虽然支持自动 UNMAP，但很多老环境还在 VMFS-5 上跑，手动回收依然是日常。我一般会把这些信息先记在记事本里，后面选方法时直接对照。

2.2 两种回收路径怎么选

方法一用 sdelete 加 vmkfstools，需要停机，适合能安排维护窗口的虚拟机；方法二用 Storage vMotion，在线迁移，不停机，但前提是目标存储有足够空间放得下这台 VM。如果你的存储池已经快满了，Storage vMotion 可能因为空间不足直接失败，这时候只能走停机回收。反过来，如果业务不能停，那就得提前规划好目标存储的容量。我通常先看存储余量：余量大于 VM 当前占用空间的 1.5 倍，优先考虑在线迁移；否则老老实实约停机窗口。

提示：不管选哪种方法，操作前对虚拟机做一次快照或者确认备份可用。回收过程中断可能导致 VMDK 损坏，有后悔药总比没有强。

3. 方法一实操：sdelete 配合 vmkfstools 停机回收

3.1 在虚拟机内清零空闲空间

这一步的核心逻辑是：Thin 磁盘之所以不释放空间，是因为删除文件时底层块只是被标记为空闲，并没有真正清零。sdelete 的作用就是把空闲块全部写零，这样 ESXi 层面才能识别出哪些块可以回收。

先把 sdelete64.exe 拷贝到虚拟机 C 盘根目录。这个工具是微软官方的命令行实用程序，下载后解压就能用，不需要安装。然后以管理员身份打开 CMD：

# -z 参数表示清零空闲空间，C: 是目标盘符 # 如果虚拟机有多个分区，每个分区都要执行一次 sdelete64.exe -z C:

执行后会看到一个进度条，时间长短取决于磁盘空闲空间大小和存储性能。我遇到过一块 500G 的 Thin 盘，空闲空间 300G，跑了将近四十分钟。期间虚拟机 IO 会明显升高，所以务必在业务低峰期做。跑完之后正常关机，不是挂起，是彻底关机。挂起状态下 VMDK 文件仍被锁定，回收命令无法执行。

3.2 在 ESXi 主机上执行空间回收

虚拟机完全关机后，SSH 登录到它所在的 ESXi 主机。先找到虚拟机的目录：

# 进入虚拟机存放目录，路径根据实际数据存储名调整 cd /vmfs/volumes/你的数据存储名/虚拟机名/ ls -lh *.vmdk

确认 VMDK 文件名，通常会有多个，比如虚拟机名.vmdk和虚拟机名-000001.vmdk。对每个需要回收的 VMDK 执行：

# -K 参数用于回收 Thin 磁盘的未使用块 vmkfstools -K 虚拟机名.vmdk

执行后会显示回收进度。这里有个细节：如果虚拟机有快照，先删掉快照再操作，否则回收的是快照文件而不是基础磁盘。回收完成后用ls -lh再看一眼 VMDK 大小，正常情况会明显缩小。我那次从 36.7G 降到了 28G 左右，和实际使用量基本吻合。

3.3 开机验证与常见异常

回收完成后启动虚拟机，进系统确认数据完好。然后在 ESXi 层面再看一次磁盘占用。如果发现 VMDK 大小没变，先检查是不是有残留快照，或者 sdelete 是否真的跑完了。还有一种情况：sdelete 执行时 C 盘空间不足导致中途失败，这时候需要先清理出足够空间再重跑。另外注意，vmkfstools -K对厚置备磁盘无效，如果误对厚盘执行，命令不会报错但也不会有任何回收效果。

4. 方法二实操：Storage vMotion 在线回收

4.1 迁移到厚置备延迟归零格式

Storage vMotion 的思路是利用格式转换来触发空间回收。当虚拟机从 Thin 迁移到厚置备延迟归零时，ESXi 会按实际使用量重新分配块，原来那些被标记为空闲但未清零的块就不会被复制过去，从而达到回收目的。

操作在 vSphere Client 里完成：选中虚拟机，右键选择「迁移」，然后选「更改数据存储」。在磁盘格式选项里，把原来的 Thin 改成「厚置备延迟归零」。目标存储要选一个有足够空间的位置，因为迁移过程中源和目标会同时占用空间。迁移时间取决于磁盘实际使用量和存储带宽，我做过一次 200G 实际数据的迁移，在千兆存储网络下大约花了二十五分钟。迁移完成后，目标存储上的 VMDK 就是厚置备延迟归零格式，占用空间等于实际使用量。

4.2 迁回 Thin 格式完成最终回收

如果你还想继续用 Thin 格式，需要再做一次 Storage vMotion，把虚拟机迁回原来的数据存储，磁盘格式选回 Thin。这次迁移同样是在线操作，不需要停机。迁回之后，VMDK 会按照实际使用量重新分配块，空间占用就是真实的精简状态。

这里有个容易翻车的点：两次迁移的目标存储不能是同一个。如果你只有一块数据存储，这个方法就走不通，因为没法在同一存储内做格式转换。另外，迁回时如果原存储空间不够，迁移会失败，所以第一次迁出后要确认原存储有足够余量接纳迁回的 VM。

4.3 在线迁移的适用边界

Storage vMotion 最大的好处是不停机，但代价是需要额外的存储空间做中转。如果目标存储空间紧张，或者虚拟机磁盘特别大，迁移窗口会拉得很长。我一般会在存储利用率低于 70% 的时候才推荐这个方法。另外，如果虚拟机挂载了裸设备映射或者有特殊存储要求，Storage vMotion 可能不支持，这时候只能回到方法一。

5. 避坑排查：回收没效果时先看这几处

5.1 现象：执行 vmkfstools -K 后 VMDK 大小没变化

原因通常是虚拟机没有完全关机，或者存在快照文件。VMDK 在虚拟机运行时被锁定，回收命令无法操作底层块。另外，如果 sdelete 没有正确执行，空闲块没有被清零，ESXi 也无法识别可回收空间。

解决：确认虚拟机状态是「已关闭」而非「挂起」，删除所有快照后再执行回收。重新在虚拟机内跑一次 sdelete，注意用管理员权限，并确认命令执行到进度条 100% 完成。

5.2 现象：sdelete 执行报错「磁盘空间不足」

原因是 sdelete 清零空闲空间时需要临时写入数据，如果 C 盘剩余空间本身很小，操作会失败。Thin 磁盘虽然物理占用可能不大，但虚拟机内看到的可用空间是逻辑大小。

解决：先清理虚拟机内的临时文件、日志、回收站，确保至少有 10% 以上的空闲空间再执行 sdelete。如果实在腾不出空间，可以先扩容虚拟机磁盘，跑完 sdelete 后再缩回去。

5.3 现象：Storage vMotion 迁移失败，提示空间不足

原因是目标存储剩余容量小于虚拟机实际占用空间，或者迁移过程中源和目标同时占用导致峰值超出。

解决：迁移前用df -h在 ESXi 主机上确认目标存储余量，建议余量大于 VM 实际占用空间的 1.5 倍。如果空间刚好卡在临界值，先清理目标存储上的无用文件，或者选择业务低峰期分批次迁移。

5.4 现象：回收后虚拟机开机蓝屏或文件丢失

原因是回收过程中 VMDK 元数据损坏，通常发生在强制中断回收命令或存储链路不稳定的情况下。

解决：操作前务必做快照或备份。如果已经出现损坏，尝试用备份恢复，或者用vmkfstools -R修复 VMDK。修复成功率取决于损坏程度，所以预防比补救重要得多。

5.5 现象：VMFS-6 环境下回收命令无效

原因是 VMFS-6 支持自动 UNMAP，但需要手动开启。如果没开启，Thin 磁盘同样不会自动回收。

解决：在 ESXi 主机上执行esxcli storage vmfs unmap -l 数据存储名手动触发 UNMAP。或者通过 vSphere Client 在数据存储属性里开启自动 UNMAP。不过很多生产环境出于性能考虑会关闭自动 UNMAP，这时候还是得用 sdelete 加 vmkfstools 的老办法。

6. 装完怎么验证：回收效果确认与日常巡检习惯

回收操作做完，别急着关窗口。验证分三层：第一层看 VMDK 文件大小，在 ESXi 主机上ls -lh确认文件确实缩小了；第二层看数据存储容量，在 vSphere Client 的存储视图里确认可用空间增加了；第三层进虚拟机系统，确认业务数据完整、应用正常启动。这三层都过了，才算真正跑通。

我一般会做一个简单的对照表来记录回收前后的数据：

如果 VMDK 大小没变但存储可用空间增加了，可能是存储层面的精简回收生效了，但文件元数据还没更新，这种情况重启 ESXi 主机或者重新挂载数据存储后会刷新。反过来，如果 VMDK 缩小了但存储可用空间没变，检查是不是有快照文件占着空间没释放。

日常巡检时，我会把 Thin 磁盘的 VMDK 大小和虚拟机内实际使用量做一个差值监控。差值超过 20% 就安排一次回收，别等到存储告警了才动手。另外，每次回收操作前强制走一遍快照流程，这已经成了我的肌肉记忆。从那以后我每次做空间回收都强制走一遍「快照→回收→验证→删快照」的流程，再也没因为回收翻过车。希望帮到你。

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