简介面向VMware虚拟化运维人员与系统管理员针对VMware精简磁盘Thin在VMFS5文件系统下无法自动回收已删除文件空间的问题提供两种经过验证的手动回收方案。方案一借助微软SDelete工具在Windows虚拟机内擦除空闲扇区后通过ESXi主机执行vmkfstools -K命令完成空间回收并给出具体操作步骤与环境示例方案二利用Storage VMotion在线迁移先将虚拟机磁盘转换为厚置备延迟归零以释放空间再按需迁回Thin格式全程无需停机适合生产环境操作。资源包含1个docx文档压缩包大小仅408KB内容结构清晰便于快速查阅。目前已有2013人学习下载适合希望掌握精简卷空间回收实操、规避存储浪费的中高级VMware管理员。文档还补充了SDelete工具下载地址、命令执行要点及迁移前后注意事项可有效帮助读者解决VMDK文件占用大于实际使用空间的常见困扰。1. VMware 精简磁盘空间不回收删了文件 vmdk 不见小处理虚拟化存储的都知道Thin精简置备磁盘最让人头疼的不是扩容而是只涨不缩。前阵子公司一台 Windows Server 2012 R2 虚机项目组删了快 20GB 的日志和临时文件数据存储的可用空间却一点没变去 ESXi 上看 vmdk 文件依然占着 36.7GB而系统里实际使用只有 27.8GB。重启、碎片整理都试过没用。这不是个例VMFS5 数据存储上的精简盘删除文件后空间不释放是常见故障很多运维第一次碰上都会怀疑是不是磁盘损坏或者有什么东西在偷偷写数据。这篇文章把两种回收方案SDelete 清零 vmkfstools 回收、Storage vMotion 迁移的完整操作和踩过的坑写清楚照着做基本能解决适合正在被“vmdk 只涨不缩”卡住的虚拟化运维。2. 根因定位VMFS5 的自动回收缺口与“假占用”识别2.1 Thin 盘的文件大小不等于虚拟机实际使用先说原理。Thin 盘刚创建时 vmdk 文件很小比如你分配了 100GB 的虚拟磁盘初始 vmdk 可能只有几 MB。虚机里每写入一块数据VMFS 才在 vmdk 文件里为这块数据分配一个块所以 vmdk 文件会随着数据增长而慢慢变大这就是“精简置备”省空间的原理。但这里有个容易被忽略的点客户机操作系统删除文件时只是把文件系统里对应的块标记为“可用”并不会把块里的内容清成零。从 VMFS 的角度看这些块仍然属于某个 vmdk 的已分配区域不能被其他虚拟机复用。于是你就看到这样的现象Windows 里使用率降下来了vmdk 文件大小却纹丝不动。判断方法很直接。虚机内看磁盘使用量ESXi 端看 vmdk 文件大小两者差距如果超过几个 GB基本就是这个情况。下面 2.3 会给具体的命令和对比方法。2.2 VMFS5 不自动回收为什么删除文件后空间不回来VMFS5 是在 ESXi 5.5 时代引入的文件系统默认不支持把客户机删掉的空间自动返还给数据存储。虽然 VMFS5 底层也知道哪些块是空闲的但“回收”这个动作需要由管理员手动触发。ESXi 的 Web Client 界面里没有“立即回收”这种按钮所以很多人根本不知道还有这个操作空间就一直在那悬空占着。对比一下 VMFS6从 ESXi 6.5 开始VMFS6 支持自动回收UNMAP虚拟机删除数据后存储空间可以异步收回。但即便在 VMFS6 上也要看磁盘类型和底层存储是否支持 SCSI UNMAP 命令。而在 VMFS5 上想回收空间只有两条路一是用 vmkfstools -K 命令手动收回二是通过 Storage vMotion 把磁盘“整一遍”。这正好对应本文后面两种方案。这里我一般会先确认数据存储的 VMFS 版本再决定方案如果数据存储是 VMFS5直接走下面的 SDelete vmkfstools 流程如果是 VMFS6 且支持自动回收可能连手动操作都不用做。2.3 怎么确认是“假占用”用数据说话不要凭感觉判断先拿到两组数据。第一组虚机内的实际使用量。Windows 在 CMD 里执行fsutil volume diskfree C:第二组ESXi 端 vmdk 文件大小。SSH 登录 ESXi 主机进入虚拟机目录执行cd /vmfs/volumes/datastore1/your-vm-directory ls -lh *.vmdk命令里的 datastore1 和 your-vm-directory 换成本机实际的存储名和目录名。ls -lh 输出里的 SIZE 列就是 vmdk 文件当前占用的空间也就是数据存储上真实消耗的空间。对比这两组数字虚机内显示 27.8GB 使用vmdk 却是 36.7GB中间差的约 9GB 就是“假占用”。这类差距在邮件服务器、数据库服务器上尤其明显——数据库删除大量数据后数据文件内部留下大量空洞vmdk 自然不可能变小。顺手再确认两件事。一是这个 vmdk 到底是不是 Thin 格式用 vmkfstools -P 查看vmkfstools -P your-vm.vmdk输出里会有一行 Capacity 和 Size如果 Capacity 远大于 Size说明是精简盘且存在空洞值得回收如果两者差不多说明是厚置备盘下面的 -K 操作对它没用。二是看有没有快照执行ls -lh | grep -i delta检查是否存在 -delta.vmdk 文件有快照的话先处理快照否则回收很容易踩坑第 5 章会细说。3. 停机回收方案SDelete 清零 vmkfstools -K 手动回收3.1 第一步Windows 里把空闲块清成零方案一的核心思路是把虚机里“已经删除但还残留着数据”的空闲块全部写成零。这样 vmdk 里那些空洞区域就会变成一长串连续的零VMFS 才能识别这些块是不需要保留的。这个清零操作要用微软 Sysinternals 的 SDelete 工具来做。下载 sdelete64.exe地址在微软官方文档的 Sysinternals 页面拷贝到 C 盘根目录。然后右键“以管理员身份运行”CMD不是普通命令行权限不够会直接报错。执行sdelete64.exe -z C:参数 -z 表示对空闲空间清零zero free space专门用于虚拟磁盘场景。执行后会显示一个进度条表示正在往空闲块写零。磁盘大或者碎片多的时候可能要跑几十分钟期间虚拟机内磁盘 I/O 会比较高建议放到业务低峰期做。几个注意事项。sdelete 默认不会处理页面文件 pagefile.sys 和休眠文件 hiberfil.sys这些文件占用的块不会被清零但这通常不影响整体回收效果因为它们的体积相对固定。如果机器有多个盘符比如 D 盘、E 盘每个逻辑盘都要单独执行一次sdelete64.exe -z D:。另外清零完成后记得把 sdelete64.exe 从系统盘删掉这类工具不适合长期留在生产系统里。3.2 第二步关机并定位 vmdk 文件清零只是准备工作真正的回收动作在 ESXi 端。为什么必须关机因为 vmkfstools -K 需要独占这个 vmdk 文件虚拟机开机状态下文件被锁定且不断有写操作回收出来的块可能马上又被数据覆盖逻辑上就乱了。所以这一步老老实实申请停机窗口。在 vCenter 或 ESXi 客户端里把虚拟机关机注意不是挂起睡眠/挂起状态 vmkfstools 依然没法安全操作。然后用 SSH 登录到虚拟机所在的 ESXi 主机。登录后先找数据存储挂载点cd /vmfs/volumes/ ls -lh这里能看到所有数据存储比如 datastore1。进去后找到虚拟机目录cd /vmfs/volumes/datastore1/你的虚拟机目录 ls -lh *.vmdkls 输出的文件名通常是“虚拟机名-000001.vmdk”这种细文件底层描述文件和“虚拟机名-flat.vmdk”这种真正的数据文件。执行 vmkfstools 时只用其中的细文件描述文件不是 -flat.vmdk这个细节很多人搞错。3.3 第三步执行 vmkfstools -K 回收空间确认目录和文件名后执行回收命令vmkfstools -K your-vm.vmdkyour-vm.vmdk 替换成刚才 ls 看到的实际文件名。这里的 -K 参数在 VMware 文档里对应 reclaim回收作用是让 vmkfstools 扫描稀疏磁盘中全零的块把它们从 vmdk 里释放掉。执行后命令行会显示回收进度测的这台 36.7GB 的 vmdk 跑完大约花了十几分钟具体时间取决于空洞比例和底层存储速度。回收完成后再ls -lh *.vmdk看一次vmdk 应该已经明显缩小。在刚才的例子中回收后 vmdk 大概能降到和 Windows 实际使用量差不多的水平。如果这个虚拟机当时还有其它描述文件比如 -delta.vmdk 快照文件需要先删快照再回收否则回收效果会被快照文件抵消。整个过程总结成一句Windows 端清零 → 关机 → ESXi 端 -K。三步缺一不可中间任何一步省了回收效果都会大打折扣。4. 在线回收方案Storage vMotion 迁移释放空间4.1 迁移到厚置备延迟归零把 Thin 盘“做实”方案二适合不能停机的环境。Storage vMotion 可以把虚拟机在不停机的情况下从一个数据存储迁移到另一个过程中利用“磁盘格式转换”完成空间回收。具体操作是在 vSphere Web Client 里右键虚拟机选择“迁移”→“更改数据存储”然后在磁盘格式那里选择“厚置备延迟归零”Thick Provision Lazy Zeroed。点击完成后系统会把虚拟机磁盘从 Thin 转换成厚置备格式。这个过程会把原 Thin 盘里实际存在的数据按实际占用完整落到新存储上那些“假占用”的空洞不会再跟着过去于是目标数据存储上的空间就释放了。厚置备延迟归零要解释一下。厚置备意味着磁盘按分配的虚拟容量预先占好位置延迟归零指位置分配时不立即写入零而是在虚拟机首次写入时才完成清零。相比“厚置备立即归零”Eager Zeroed Thick它的迁移速度更快。这里选择延迟归零就够了除非这台虚拟机的磁盘之后要承载集群或需要立即置零的应用场景。4.2 再迁回 Thin把磁盘格式变回去到这里空间已经收回来了但问题在于磁盘变成了厚置备容量占用是分配值比如 100GB 的盘就占 100GB而不是实际使用量。对大多数业务来说这不可接受所以通常还要再做一步把它迁回 Thin。再右键虚拟机→“迁移”→“更改数据存储”这次选择回原来的数据存储磁盘格式选“Thin精简置备”。迁移完成后磁盘格式变回 Thin。同时因为源和目标的实际占用都已经是最新的所以新 Thin 盘的大小会以实际使用量为基准空间被彻底释放。这一来一回的迁移会产生两块磁盘同时在线的时段。第一趟从 A 迁到 BB 存储要能装下转换后的厚置备卷第二趟从 B 迁回 AA 存储同样要有充足空间。很多人在第一步就忽略了目标存储剩余空间结果迁移到一半提示空间不足虚拟机卡在迁移状态。所以执行之前先在数据存储列表里确认两边可用空间都大于虚拟机分配容量而不是大于实际使用量——厚置备是按分配容量占空间的。5. 避坑与常见问题回收空间翻车的几种典型现场5.1 快照没删回收后空间反而更大现象虚拟机关机后执行 vmkfstools -K完成后 ls -lh 一看vmdk 没小反而多出来一个很大的 -delta.vmdk或者回收前后总占用没变化。原因虚拟机存在快照时vmdk 文件被拆成原始盘加多个快照 delta 文件。-K 只处理指定的 vmdk 描述文件不会去处理快照链里其它 delta 文件而且原始盘在这个状态下的块映射也不是完整的回收等于白做。解决进 vCenter 删掉全部快照等快照删除合并完成后再关机动 vmkfstools -K。注意删快照时存储需要有足够空间容纳合并过程尤其是快照已经很大的情况下。5.2 sdelete64.exe 执行报错或提示无法清理部分文件现象在虚机内执行sdelete64.exe -z C:跑到一半报错常见的有“拒绝访问”、无法打开文件或者进度条卡在 90% 不动。原因一是权限不够普通 CMD 跑不了 -z 清零操作必须管理员权限。二是某些文件被占用或系统文件不能写零比如 pagefile.sys、休眠文件以及正在被防病毒软件实时扫描的文件。三是磁盘有坏道或策略限制了写入这个相对少见。解决确认用管理员身份打开 CMD。暂时关闭杀毒软件的实时防护再执行。把 Windows 的页面文件先临时移动到其它盘或设置为无跑完再还原。SDelete 有个 -r 参数可以指定重试次数比如sdelete64.exe -r 5 -z C:遇到瞬时占用可以提高成功率。如果最后还剩小部分文件清理不了先执行完 vmkfstools -K 看整体回收效果小于 1GB 的残留通常影响不大。5.3 vmkfstools -K 执行后文件大小纹丝不动现象SSH 到 ESXi 执行 vmkfstools -K xxx.vmdk命令很快就返回了ls -lh 看文件大小没有变化。原因最常见的是这个 vmdk 根本不是 Thin 格式而是厚置备或厚置备延迟归零。-K 只对稀疏精简盘有效对厚盘没有回收语义。其次虚拟机处于开机或挂起状态vmdk 被锁定命令实际上没成功操作。解决先用vmkfstools -P xxx.vmdk确认文件类型如果显示是 thick回收根本没意义换 Storage vMotion 方案把格式转成 Thin 再迁移。如果是锁定问题把虚拟机关机确认 vCenter 里该虚拟机已停止再重新执行。另外老的 ESXi 版本对 -K 的支持不完整如果 ESXi 版本过旧建议走 vMotion 方案。5.4 迁移 Thin 到 Thin空间毫无变化现象用 Storage vMotion 从 A 存储迁到 B 存储磁盘格式选“与源相同Thin”结果迁移完成后 B 存储上 vmdk 大小和原来一模一样。原因这正是 Thin 空洞跟着走的结果。如果源和目标都是 Thin 格式vMotion 只会做数据复制不会主动去识别和丢弃全零块回收效果为零。这也是为什么方案二必须先走一遍厚置备延迟归零、再迁回 Thin 的原因——中间必须有一个“把盘做实”的环节才能把空洞挤掉。解决按 4.1 和 4.2 的顺序完整走两趟中间别跳步。如果只想保留 Thin第二趟选目标格式为 Thin 即可但要确保第一趟厚置备迁移成功了。有个检查手段第一趟迁移完成后登录 ESXi 看一眼新的 vmdk 大小应该等于或接近该磁盘在源端的实际占用而不是原 vmdk 文件大小。5.5 多个分区和数据库文件场景回收效果不如预期现象Windows 虚机有 C、D 两个盘只执行了sdelete64.exe -z C:回收后空间只释放了一部分。原因每个分区都需要单独清零C 盘清了但 D 盘上空闲块还是原始数据vmdk 里 D 盘区域依然占用。另一个常见场景是数据库的数据文件比如 SQL Server 的 MDF 文件内部包含大量空闲页这些页在文件系统层面属于“已分配”SDelete 不会去清文件内部的空间所以回收效果有限。解决所有数据盘分别执行清零。数据库文件的情况回收到合理程度即可如果一定要求最小占用可以在数据库内收缩文件后再清零回收。不过数据库收缩本身有风险建议在维护窗口操作并且收缩后记得重建索引否则碎片会拖慢写入性能。6. 快速定位与验证三分钟判断该走哪条回收路线遇到“vmdk 只涨不缩”先按下面这个顺序过一遍三分钟内就能定位该用哪个方案。第一步虚拟机关机状态下SSH 登录 ESXi进入虚拟机目录执行ls -lh *.vmdk看文件大小再执行vmkfstools -P *.vmdk确认磁盘格式。如果格式是 thin 且 vmdk 大小明显大于虚机内实际使用大概率可以回收。第二步ls -lh | grep -i delta检查有没有快照文件。有快照先去 vCenter 删除快照没快照再继续。这一步决定你走方案一还是方案二——有快照的话方案二更合适因为在线迁移会把快照链合并掉一部分空间。第三步看业务能不能停机。能停机走 SDelete vmkfstools -K成本最低不能停机走 Storage vMotion 两趟迁移。注意选择前先看数据存储可用空间迁移路线的目标存储必须能装下厚置备格式这个坑前面已经专门说过。验证回收是否成功看三处数字验证点命令预期结果数据存储可用空间df -h /vmfs/volumes/datastore1回收后可用空间明显增大vmdk 文件大小ls -lh *.vmdk文件缩小接近虚机实际使用量磁盘格式vmkfstools -P *.vmdk确认已是 thin 且 Size 小于 Capacity刷新 vCenter 存储视图正常情况下数据存储使用率的柱子也会掉下来。如果数字没变回头检查是不是快照没清、格式选错了或者 vmkfstools -K 命令打在了 -flat.vmdk 上要打在描述文件上。从那以后我给新虚拟机做资源规划时都把精简盘回收写进交付清单磁盘格式确认、快照清理、回收窗口三项全走一遍才交付尤其是数据库和文件服务器这类删除操作频繁的机器。空间“假占用”不会自己消失定期手动回收一次远比临到存储耗尽再想办法轻松。希望这份排错笔记能帮你少走几步弯路。本文还有配套的精品资源点击获取