简介这份文档面向 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 文件大小36.7G28G 左右接近实际使用量数据存储可用空间紧张增加约 8G与 VMDK 缩小量一致虚拟机内磁盘使用量27.8G27.8G不变磁盘格式ThinThin方法一或厚置备延迟归零方法二中间态按需选择如果 VMDK 大小没变但存储可用空间增加了可能是存储层面的精简回收生效了但文件元数据还没更新这种情况重启 ESXi 主机或者重新挂载数据存储后会刷新。反过来如果 VMDK 缩小了但存储可用空间没变检查是不是有快照文件占着空间没释放。日常巡检时我会把 Thin 磁盘的 VMDK 大小和虚拟机内实际使用量做一个差值监控。差值超过 20% 就安排一次回收别等到存储告警了才动手。另外每次回收操作前强制走一遍快照流程这已经成了我的肌肉记忆。从那以后我每次做空间回收都强制走一遍「快照→回收→验证→删快照」的流程再也没因为回收翻过车。希望帮到你。本文还有配套的精品资源点击获取