简介这份文档面向使用 VMware 虚拟化平台、并受精简磁盘Thin空间膨胀困扰的运维人员与虚拟化学习者聚焦 VMFS5 文件系统不支持自动回收空间这一痛点讲解手工回收 VM 精简卷容量的可行路径。压缩包内仅含 1 个 docx 文件约 408KB篇幅紧凑、以图文步骤为主便于在故障排查现场直接查阅。文档以实际环境为例虚拟机实际占用 27.8G、VMDK 却达 36.7G完整记录了 SDelete 清零空闲空间配合 vmkfstools -K 离线回收以及通过 Storage VMotion 切换厚置备延迟归零再迁回 Thin 的在线方案并附有工具下载地址、命令写法与执行过程中的等待要点。已有 2021 人学习下载适合需要快速定位空间浪费原因、建立回收操作流程的初中级管理员参考。1. 一台只跑业务系统的虚拟机占用了 36.7G客机只显示 27.8G一台 Server 2012 R2 虚拟机客机里查看磁盘实际使用 27.8G数据存储上那个 VMDK 却稳稳占着 36.7G。日志清了两轮、安装包删了一批客机数字降下来了VMDK 的占用却一动不动。做 VMware 精简磁盘空间回收这件事几乎都是从这种“账对不上”的场面开始的Thin 磁盘只在写入时分配块删除动作在客机文件系统里完成到 VMFS 这一层就断了线被删掉的块依然挂在原来那个 VMDK 名下。这套方案要解决的就是最后这一步让已经删掉的数据真正在数据存储上退租。它适合两类人一类是手里攒了一批 Thin 虚拟机、数据存储余量已经开始告警的运维另一类是要交一份存储空间治理方案的学生或初级工程师需要既有原理、又能照着自己做一遍、还能拿出验收证据。下面按“空间账怎么算、两条回收路线怎么落地、哪些地方容易翻车、最后怎么证明回收生效”的顺序往下推。2. Thin 磁盘的空间账本三块容量口径与 VMFS5 的回收缺口要判断一次回收到底有没有用先得把“空间”这个词拆成三份因为它们根本不是同一个数。三份口径对不上是所有后续排查的起点也是最容易被忽略的一步。2.1 三块容量口径客机已用、VMDK 占用、数据存储剩余客机口径是文件系统自己记的账。Windows 的卷属性、Linux 的df -h报的都是“文件系统认为已分配的块”。文件删掉的那一刻这个数字就往下走了。VMDK 口径是 VMFS 记的账。数据存储浏览器里看到的.vmdk文件大小或者 SSH 上去ls -l出来的字节数反映的是这块磁盘在 VMFS 上真实占住、已经被分配出去的块。Thin 磁盘的分配只增不减块一旦分给它除非显式回收否则永远算在它头上。数据存储口径是整卷的账。卷的已用容量 所有 VMDK 快照 delta swap 文件 日志。这一层最容易吓人因为它把快照的占用也算进去了经常出现“虚拟机才 40G数据存储少了 200G”的情况多数时候是快照链在吃空间。正常情况下客机口径 ≤ VMDK 口径 ≤ 数据存储口径三者不该差太多。差出几个 G 甚至十几个 G通常来自这几个方向被删除但还被进程句柄占用的文件、NTFS 的 MFT 保留区、页面文件和休眠文件、系统还原点、以及最关键的——Thin 已经分配出去却再也没被使用的块。前几项在客机侧就能处理最后一项必须回到存储层动手这就是回收要解决的问题。2.2 VMFS5 为什么把回收这件事留给了人工Thin 的分配逻辑本身没有问题写多少分多少不写不占。问题在于“退租”这个反向动作需要有明确的信号告诉存储层“这块我不要了”而这个信号在 VMFS5 上是缺位的。客机文件系统删除文件时只在自己的元数据里把块标记为空闲不会主动去通知底层存储。要让存储知道中间需要一条 UNMAP/TRIM 的通道客机发得出来、虚拟磁盘控制器传得过去、VMFS 收得下并且真的把块还回空闲池。VMFS5 这条链路是不完整的卷层没有后台回收线程也没有面向客机的透传能力唯一可用的入口就是 ESXi 命令行上那个显式的打洞工具vmkfstools -K。它做的事很朴素——扫描 VMDK把全零的块标记为未分配还回数据存储的空闲池。到了 VMFS6卷层才把自动 UNMAP 做进来还配了esxcli storage vmfs unmap这样的手动触发入口可以按数据存储粒度发起回收并做节流。所以如果你在 VMFS5 的卷上执行 unmap 命令报“Operation not supported”是正常的版本差异不是你命令写错了。这也是为什么输入里那套流程必须走vmkfstools -K——它不是绕路是 VMFS5 上唯一的正路。提示先确认卷是 VMFS5 还是 VMFS6再决定走哪条命令。版本没确认就上手是这个场景里最常见的无效劳动。2.3 两条回收路线的取舍离线清零与在线迁移明确了缺口在存储层接下来有两条路可以补。第一条是离线清零。先在客机内把空闲空间写成零让“哪些块是垃圾”这件事在 VMDK 内容里变得可识别关机之后在 ESXi 上跑vmkfstools -K把这些零块打洞还回去。它的好处是精准、不需要额外的存储空间、对存储阵列没有特殊要求代价是必须停机而且停机窗口的长度取决于 VMDK 有多大、后端存储的 IO 能力如何。第二条是在线迁移。用 Storage vMotion 把虚拟机迁到另一个数据存储迁移过程中磁盘格式选厚置备新生成的磁盘会按“真实有数据的块”重新分配迁完再迁回来格式选回 Thin占用自然就降下来了。它的好处是不停机坏处是目标存储必须能放下按配置大小算的厚置备磁盘而且来回两趟的迁移时间不短。两条路不是互斥的实际项目里经常先用迁移处理不能停机的业务机再用离线清零处理可以约时间窗的机器。选哪条看的是“能不能停”和“有没有第二块存储”这两个条件而不是哪条更先进。3. 方案一落地SDelete 清零配合 vmkfstools -K 的完整流程这条路线四步走检查、清零、打洞、验证。每一步都有前置条件跳过任何一步都会在最后一步卡住。3.1 动手前的四项检查第一项是快照。虚拟机上挂着快照时磁盘写入会落到 delta 文件里vmkfstools -K对基础磁盘打洞要么直接失败要么打完洞空间也释放不出来因为占空间的是 delta 不是基础盘。有快照的先在快照管理器里全部删除并等待合并完成再往下走。第二项是客机空闲空间。SDelete -z的做法是往空闲块里写零空闲空间太少会让这一步跑得极慢而且写零本身会临时占用更多空间。通常的做法是保证客机至少有两成以上空闲实在腾不出来就先扩一块临时盘或者迁走一部分数据。第三项是 SSH 服务和执行窗口。ESXi 主机默认关闭 SSH在主机管理界面的服务里启动并把启动策略改成“随主机启动”或手动启动用完记得关掉。同时确认这个时间窗内虚拟机可以关机业务侧已经通知到位。第四项是记录基线。回收前后要有对比基线就得提前记。在 ESXi 上把这个虚拟机的目录列一遍把 VMDK 的字节数抄下来数据存储的已用容量也截个图。# 列出所有虚拟机拿到目标虚拟机的 Vmid vim-cmd vmsvc/getallvms # 查快照输出里没有有效的 Snapshot Name 才算干净 vim-cmd vmsvc/snapshot.get 12 # 查电源状态必须是 Powered off 才能进下一步 vim-cmd vmsvc/power.getstate 12 # 记录基线VMDK 实际占用与数据存储剩余 ls -l /vmfs/volumes/datastore1/VM-APP-01/ df -h /vmfs/volumes/datastore1getallvms输出的第一列就是 Vmid后面几个命令都要用它。snapshot.get在没有快照时输出里不会出现有效的快照名只会有分隔行看输出时别被格式误导。df -h看的是整卷ls -l看的是单个文件两个数都要记因为最后验收时它们要能互相印证。3.2 SDelete 参数选择与清零执行SDelete 是 Sysinternals 套件里的一个命令行小工具用途是清理逻辑磁盘上的空闲空间。它有两个常用模式-c清理可用空间会反复覆写更彻底但更慢-z清零空闲空间只写一遍零速度快正好适合虚拟化场景。我们这里的目的是让 VMDK 里的空闲块变成全零让vmkfstools -K能识别出来所以选-z。把sdelete64.exe拷到客机的 C 盘根目录用管理员权限开命令提示符执行:: -z 清零空闲空间只写一遍零速度快适合配合 vmkfstools -K :: -p 1 指定覆写次数配合 -z 时用默认值即可 :: -s 递归子目录-z 模式下一般不需要仅在清理目录时使用 :: -q 安静模式不输出每个文件的处理信息 sdelete64.exe -z C:执行后会看到一个百分比进度条走完就结束了。这一步的耗时和空闲空间大小、磁盘 IO 直接相关几十 G 空闲空间跑十几分钟到半小时都算正常如果卡在某个百分比长时间不动先去看客机磁盘队列和存储侧的 IO 延迟而不是急着重启。需要强调一点-z只写空闲块不动任何有效数据所以不需要额外的备份动作但它会大量消耗 IO跑在业务时段可能拖慢同存储上的其他虚拟机能约到低峰期就约低峰期。多分区的虚拟机要逐个处理。测试环境里只有 C 盘一条命令就够生产机上常见 C、D 两个分区-z C:之后还得-z D:漏掉哪个分区那个分区对应的那部分 VMDK 空间就回收不掉——这也是后面排查章节里会反复出现的一个坑。3.3 关机后在 ESXi 上执行 vmkfstools -K清零完成客机内的工作就结束了。接下来关机然后通过 SSH 登录到虚拟机所在的 ESXi 主机进到虚拟机目录执行打洞。# 进入虚拟机所在目录目录名一般就是虚拟机显示名 cd /vmfs/volumes/datastore1/VM-APP-01 # 再确认一次电源状态必须是 Powered off vim-cmd vmsvc/power.getstate 12 # 执行打洞-K 等价于 --punchzero把全零块标记为未分配 # 参数是具体的 vmdk 文件名不要用 *.vmdk 一把梭 vmkfstools -K VM-APP-01.vmdk-K的作用是把 VMDK 里内容全零的块打洞还回数据存储的空闲池。这个操作只对 Thin 格式的磁盘有效厚置备磁盘跑它没有意义。执行时会有百分比进度进度条走完会打印一句完成信息中间不要 CtrlC 中断——中断之后磁盘文件本身不会损坏但已经打过的洞不会回滚下次还得从头扫一遍白等一轮。关于*.vmdk目录里通常不止一个 vmdk 文件可能还有-flat.vmdk、快照 delta、以及独立磁盘。直接写通配符有风险最好先用ls -l看清文件名再逐个指定。有独立磁盘比如单独挂的数据盘的每个都要打一遍。耗时上vmkfstools -K的时长和 VMDK 配置大小、后端存储的随机读性能强相关。一个几十 G 的盘跑十几分钟很常见几百 G 的盘跑一两个小时也不稀奇。判断是不是卡死看 ESXi 主机上的存储 IO 是否还有活动别只盯进度条。3.4 回收结果的三种验证口径打完洞之后光看一个数字不够三个口径都要对一遍对得上才算真的回收成功。# 口径一VMDK 文件实际字节数回收后应明显小于回收前 ls -l /vmfs/volumes/datastore1/VM-APP-01/VM-APP-01.vmdk # 口径二数据存储已用容量回收后应下降 df -h /vmfs/volumes/datastore1 # 口径三回到 vSphere 客户端的数据存储摘要页看已用空间的图形变化三个口径的对应关系是ls -l看到的是这个 VMDK 自己的占用df -h看到的是整卷客户端摘要页是给人看的可视化。回收前后各记一次差值应该大致相当。如果ls -l降了但df -h没怎么动去查这个卷上是不是还有别的虚拟机在同一时间写了大量数据把回收出来的空间又吃掉了。还有一种情况三个数都降了但降的幅度远小于预期。多半是客机里还有别的分区没清零或者 VMDK 里存在大量非零的“垃圾块”比如被反复覆写过的临时文件区域。前者补一遍-z后者只能接受——Thin 回收的是全零块非零块没法打洞。4. 方案二落地Storage vMotion 厚置备往返的在线回收不能停机的机器走这条。核心思路不是“打洞”而是“重建”让 vMotion 在目标存储上重新生成一份磁盘新磁盘只为真实数据分配块旧的连同它的历史包袱一起被丢掉。4.1 磁盘格式三选一为什么中转站要用厚置备延迟归零vSphere 里给虚拟磁盘选格式时有三个选项含义完全不同。Thin 是按需分配写多少分多少这也是产生回收问题的根源。厚置备延迟归零是按配置大小一次性把空间划出来但块内容不预先清零第一次写入时才做零化处理。厚置备置零同样按配置大小划空间而且在创建时就把所有块写成零速度最慢、占用最大但换来了最好的首次写入性能和某些集群特性上的兼容性。往返迁移的中转站要选厚置备延迟归零理由是这个格式下“配置大小 实际占用”vMotion 完成后目标存储上的磁盘块分布完全按真实数据重新生成原来那些分配出去但没用的块就自然消失了。迁回 Thin 时新磁盘只会为“确实有内容”的块分配空间占用自然降下来。不用厚置备置零的原因很简单它会全盘写零耗时更长而这个场景里我们并不需要零化带来的那些额外好处。也不用 Thin 做中转——从 Thin 迁到 Thin块分配逻辑不变回收效果约等于零。磁盘格式空间分配方式首次写入迁移耗时适合做中转精简置备Thin按需分配只增不减正常短不适合等于没迁厚置备延迟归零按配置大小划出写入时零化略慢中等适合最常用厚置备置零按配置大小划出并全盘零化快长可用但没必要4.2 往返迁移的完整步骤与耗时预估界面上操作是最直观的选中虚拟机右键迁移选择“仅更改存储”目标数据存储挑一块有足够余量的虚拟磁盘格式选“厚置备延迟归零”下一步确认等任务完成。第一程结束后占用没降反而涨了是正常的——这时候它是厚置备按配置大小占着。第二程再迁回原数据存储格式选“精简置备”完成之后占用才会掉下来。批量处理的时候用 PowerCLI 更省事# 连接 vCenter凭据按实际环境替换 Connect-VIServer -Server vcenter.example.internal -User administrator -Password ****** $vm Get-VM -Name VM-APP-02 $dsA Get-Datastore -Name DS-PROD-01 # 原数据存储 $dsB Get-Datastore -Name DS-PROD-02 # 中转数据存储需有足够余量 # 第一程Thin - 厚置备延迟归零把磁盘重建一遍 Move-VM -VM $vm -Datastore $dsB -DiskStorageFormat LazyZeroedThick -Confirm:$false # 第二程厚置备延迟归零 - Thin按真实数据重新分配块 Move-VM -VM $vm -Datastore $dsA -DiskStorageFormat Thin -Confirm:$false Disconnect-VIServer -Confirm:$falseMove-VM的-Datastore指定目标存储-DiskStorageFormat的取值对应界面上的三个选项LazyZeroedThick是厚置备延迟归零Thin是精简置备。两程之间不要加别的操作尤其别在这中间创建快照否则第二程的格式转换会被跳过或直接报错。耗时预估按“实际占用 ÷ 迁移带宽”来算而不是按配置大小。一条千兆链路上跑几十 G 的实际数据一两个小时是常态如果存储侧还有别的负载时间会更长。批量做的时候建议排个队一次迁两三台别一次性把十几台全部推进去否则存储带宽被打满所有业务一起变慢。4.3 迁移期间的四个风险控制点第一个是目标存储容量。厚置备按配置大小算不是按实际占用算。一台配置了 500G、实际只用了 80G 的虚拟机迁过去要占 500G。做之前把目标存储的剩余容量和这批虚拟机的配置大小总和算一遍留出两成冗余。这是这条路线最常见的翻车点没有之一。第二个是快照。虚拟机上有快照时vMotion 改磁盘格式的行为会受限轻则格式转换被跳过白迁一趟重则任务直接失败。迁之前先合并快照。第三个是迁移带宽。vMotion 和业务流量共享物理网卡迁移期间别在同一存储上再安排备份、克隆、批量部署这类重 IO 任务。有条件的话给 vMotion 单独配 vmnic或者在网络 IO 控制里给迁移流量设个上限。第四个是迁移完成后的确认。迁移任务显示“已完成”不等于格式换对了回到虚拟机的磁盘设置里看一眼确认磁盘格式确实是预期的那个再看数据存储的已用容量。这一步花不了一分钟能省掉后面一堆扯皮。4.4 两种方案怎么选一张对比表对比项离线清零SDelete vmkfstools -K在线迁移Storage vMotion 往返是否需要停机需要打洞期间虚拟机关机不需要全程在线额外存储空间不需要需要按配置大小算单台耗时中等取决于 VMDK 大小和存储 IO较长来回两趟迁移对客机的要求能进系统执行命令能腾出空闲空间无回收彻底程度只回收全零块非零垃圾块无法打洞按真实数据重建更彻底适用场景可约时间窗的业务机、测试环境不能停机的核心业务、批量治理主要风险快照未清、多分区漏做目标存储容量不足、格式选错一般的选择顺序是能停机、存储没余量的走离线清零不能停机、有第二块存储的走在线迁移两样都不满足的先扩存储或者先清理客机内的大文件再回来做回收。别硬凑条件这条路没有捷径。5. 避坑与排查五条现场最容易翻车的经验这五条基本覆盖了这个场景里九成以上的“做了但没效果”。5.1 打完洞空间没降快照还在现象vmkfstools -K跑完了进度条也走到底ls -l看 VMDK 一点没变。原因虚拟机上有快照当前磁盘写入全在 delta 文件里基础 VMDK 的内容并没有变化打洞自然打不出东西。有些情况下命令会直接报错退出有些情况下它会“成功”但毫无效果后者更坑。解决先vim-cmd vmsvc/snapshot.get vmid确认快照状态有快照就全部删除并等待合并完成再重新跑一遍清零和打洞。合并本身也需要时间别合并完立刻跑等任务确实结束。5.2 只处理了 C 盘D 盘的空间纹丝不动现象回收做完了C 盘对应的那部分空间降了整体占用只降了一小截。原因sdelete64.exe -z C:只处理 C 盘的空闲块D 盘、E 盘的空闲块没被写成零vmkfstools -K扫到这些区域时看到的是非零内容不会打洞。解决进客机用磁盘管理确认分区数量逐个分区执行清零。注意-z后面跟的是盘符加冒号多分区机器要跑多次。跑完再关机打洞一次到位。5.3 vmkfstools -K 报错“Failed to punch zero”或提示文件被占用现象命令一执行就报错退出或者提示无法打开 VMDK。原因最常见的是虚拟机没真正关机挂起状态不算关机或者虚拟机上还挂着别的进程在读写磁盘。也有可能是路径写错了或者指定的文件是-flat.vmdk而不是描述符文件。解决vim-cmd vmsvc/power.getstate vmid确认是 Powered offcd到目录后ls -l看清文件名参数用描述符.vmdk而不是-flat.vmdk确认没有正在运行的克隆、备份、快照合并任务。5.4 迁移完成后容量不降反升现象Storage vMotion 跑完数据存储占用比迁移之前还高。原因第一程迁成了厚置备按配置大小占空间这是预期行为不是故障。真正的问题在于很多人只做了第一程就以为结束了或者第二程的格式没选回 Thin。解决确认两程都执行完且第二程的-DiskStorageFormat是Thin。如果第二程也做完了还是不降去查虚拟机是不是还有快照——有快照时格式转换会被跳过迁移任务依然会显示成功。5.5 在 VMFS5 上跑 unmap 命令报不支持现象esxcli storage vmfs unmap -l DS-PROD-01执行后提示操作不被支持。原因自动 UNMAP 是 VMFS6 才有的能力VMFS5 的卷层没有这条通道。命令本身没写错是版本不匹配。解决确认卷版本VMFS5 就老老实实走vmkfstools -K。别为了用上新命令去升级卷——升级卷涉及整个数据存储的兼容性代价远大于收益而且升级完老的 VMFS5 卷也不会自动变快。6. 验收与答辩三条证据链和一套五分钟演示回收这件事最容易吃的亏是活干了但说不清。三块口径的数都降了可要是拿不出前后对比别人一句“会不会是别的机器删了东西”就能把你问住。所以验收要按证据链来做不是看一眼数字了事。第一份证据是数字对齐表。回收前后各记一次三个口径写在同一张表里差值能对上。记录项采集位置回收前回收后差值客机已用空间客机df -h或卷属性27.8G27.6G-0.2GVMDK 实际占用ESXi 上ls -l描述符36.7G28.4G-8.3G数据存储已用df -h /vmfs/volumes/...按实际填按实际填与上一行接近磁盘格式虚拟机磁盘设置ThinThin未变快照数量快照管理器000第二份证据是时间线。几点开始清零、几点关机、几点开始打洞、打洞跑了多久、几点完成验证一条时间线列清楚。这份东西的价值在于出问题时能快速定位是哪一步拖了后腿答辩时被问到“为什么用了这么久”也有据可依。第三份证据是复现脚本。把这次用到的命令整理成一个可重复执行的清单换一台机器改改路径就能跑。我一般会把检查项也写进去让下一个接手的人不至于从零摸索。#!/bin/sh # 精简磁盘回收后的快速核对脚本在 ESXi 主机上执行 VM_DIR/vmfs/volumes/datastore1/VM-APP-01 VMDKVM-APP-01.vmdk echo 磁盘格式与容量 ls -lh $VM_DIR/$VMDK echo 数据存储剩余 df -h /vmfs/volumes/datastore1 echo 是否存在快照 delta 文件 ls -1 $VM_DIR | grep -i delta\|-00000 || echo 无快照 delta脚本里最后那行用grep找 delta 文件是这套流程里我最常用的一个自查手段——目录里只要出现-000001.vmdk这类文件就说明还有快照链这时候别急着做任何回收动作。答辩环节真正会被追问的通常只有三个问题为什么不能自动回收答 VMFS5 卷层没有 UNMAP 通道只有 VMFS6 才有为什么打洞前要先清零答vmkfstools -K只识别全零块客机里删掉的数据在磁盘上还是原来的内容不打洞两条路线怎么选答看能不能停机、有没有第二块存储。这三个问题答得清楚方案就算立住了。从那以后我每次做这类回收都会在动手前把那张数字对齐表的表头先建好回收前一行、回收后一行中间的过程日志附在下面。吃过一次亏——有回只记了数据存储的剩余容量结果那段时间同卷上另一台机器正好在灌数据回收出来的空间被吃掉一大半数字对不上查了大半天才发现是隔壁机器干的。希望帮到你。本文还有配套的精品资源点击获取
