简介围绕VMware精简磁盘空间回收整理的实战文档面向虚拟化运维人员、ESXi平台使用者以及需要排查存储容量异常的技术人员重点解决Thin磁盘在vmfs5环境下无法自动释放空间、VMDK占用持续膨胀的问题。压缩包共1个docx文件大小约408KB内容以图文步骤、命令说明和场景对比为主便于按实际环境查阅。文档结合Windows虚拟机磁盘实际使用量与VMDK占用不一致的现象梳理精简卷回收机制并对比SDelete清理空闲空间后停机执行vmkfstools回收以及通过Storage vMotion迁移、转换厚置备延迟归零再迁回Thin的在线处理方式说明两者在停机要求、目标存储容量和操作复杂度上的差异同时给出回收后的验证思路。已有2021人学习或下载适合需要处理存储容量告警、优化精简磁盘占用并补充ESXi存储管理经验的读者参考。1. 删了 20G 日志VMDK 一点没瘦Thin 盘最反直觉的一幕在 Thin 精简置备的虚拟机里删掉一大堆日志进数据存储一看vmdk 大小纹丝不动——这是 VMware 精简磁盘空间回收里最经典的一幕。我遇到的那次客户机磁盘实际只用了 27.8GVMDK 却实打实占着 36.7G中间差了将近 9G 的“幽灵空间”。vmfs5 不支持自动回收你在客户机里删文件只是改了文件系统的元数据底下的块还挂在你账上。这类故障不报错、不影响业务只在存储告警冲到 80% 的那天集中爆发折腾起来往往要停机窗口。适合所有在 ESXi 上跑 Thin 盘、被“空间去哪了”问住过的运维和开发照着后面的顺序排查一遍。2. 空间为什么回收不掉vmfs5 的 UNMAP 缺口和三种假象2.1 删文件只是改元数据块并没有还给存储先把链路拆开看。客户机里的文件系统NTFS、ext4删文件时做的是把 inode 或 MFT 记录标记为空闲数据块的内容原封不动躺在磁盘上。Thin 磁盘的“瘦”依赖底层能感知哪些块已经没用了客户机告诉虚拟磁盘控制器“这块我不要了”TRIM/UNMAPESXi 再把消息传给 VMFSVMFS 把这部分块标记为空闲并归还给数据存储。这条链路任何一环断了vmdk 就只能一直胖着。vmfs5 恰恰断在最后一环。常见的说法是 vmfs5 不把客户机的 UNMAP 请求往下传即使你的虚拟磁盘控制器已经是 PVSCSI、客户机是 Windows Server 2012 R2 及以上跑Optimize-Volume -ReTrim也是空转。真正把自动 UNMAP 做进来的是后来的 VMFS6而且在那边还要客户机、虚拟硬件版本、ESXi 版本三方对齐才生效。所以在一堆还在用 vmfs5 的老环境里别指望“删了就会自动瘦”这件事从来都得手动做。手动做的思路也不复杂既然系统不知道哪些块是空闲的那就主动把空闲块写成明确的 0SDelete、zerofree、dd都能干vmdk 里于是出现大片连续的全零块再让 ESXi 把这些零块“打洞”回收vmkfstools -K。零是确定值不是“未知”这就是整个回收方案能成立的物理基础。理解这一点后面所有报错你都能自己推。2.2 三种“以为回收了”的假象第一种假象最常见在客户机里跑了一遍磁盘清理、碎片整理甚至fstrim看进度条跑完了就以为搞定。碎片整理反而更糟它会把原本空闲的块搬来搬去可能让 vmdk 更胖。fstrim在 vmfs5 上不会有任何下层效果命令返回成功只代表客户机侧执行完了。第二种是看错了指标。vSphere Client 里虚拟机磁盘有两组数字已置备空间Provisioned和使用空间Used。Thin 盘的“已置备”是你创建时给的上限永远不变“已使用”才是真正占着数据存储的量。很多人盯着已置备空间纳闷为什么不降其实应该看的是 vmdk 文件在数据存储里的实际落盘大小。第三种是缓存和刷新。vmkfstools -K跑完之后Client 界面上的存储用量有延迟有人看一眼没变就以为失败了转头又跑一遍。判断成功的唯一可靠方式是回 ESXi Shell 用ls -lh看文件大小别信界面。提示在动手之前先确认数据存储的块大小和 VMFS 版本。vmfs5 统一 1MB 块回收粒度以 MB 计所以你删掉几百 KB 零碎文件基本看不到变化别为这点空间白折腾。2.3 先做决策SDelete 打洞还是 Storage vMotion摆在你面前的两条路本质完全不同。方法一是“客户机清零 ESXi 打洞”只处理已删除的空闲空间速度快、对存储的额外占用小但要求虚拟机停机。方法二是 Storage vMotion把虚拟机整盘复制到另一个数据存储副本按实际使用量重新落盘天然就是瘦的全程在线但要拷贝全量数据、要有第二块存储、动辄几小时。我一般按这张表决策判断维度SDelete vmkfstools -KStorage vMotion是否需要停机需要虚拟机必须关机不需要在线迁移耗时量级与空闲空间大小相关通常几十分钟与磁盘已用总量相关通常数小时对生产 IO 的冲击集中在清零阶段峰值高全程持续拷贝长时间占用带宽额外存储需求无目标存储需容纳整机已置备容量能否顺带改磁盘格式不能能厚置备、Thin 随你选适用场景有维护窗口、只有一块存储不能停机、要换存储或改格式选错的代价不小。有次维护窗口只留了两小时有人选了 vMotion一个 2TB 的盘拷到一半窗口结束只能中断白折腾。反过来只有一块存储、又想在线瘦身那就没得选——先把空间腾出来再说。3. SDelete vmkfstools -K 实操从 36.7G 打回 27.8G3.1 客户机侧把空闲空间写成零SDelete 是微软 Sysinternals 套件里的命令行工具作用是按你指定的方式处理逻辑磁盘上的空闲空间。它需要在客户机里跑所以先把sdelete64.exe传进虚拟机。我习惯直接丢到C:\根目录路径短、不容易被权限拦住。用管理员权限打开 CMD别用普通窗口否则写磁盘会直接失败:: 切到工具所在目录示例放在 C 盘根目录 cd /d C:\ :: -z 表示把空闲空间清零这是虚拟化场景专用的模式 :: -q 关闭交互提示-nobanner 去掉启动横幅输出更干净 sdelete64.exe -z C: -q -nobanner参数上要分清-z和-c-c是清理空闲空间用随机数据覆盖再删适合安全擦除-z才是清零专门喂给精简磁盘回收用。用-c只会让 vmdk 更胖因为随机数据不构成连续零块打洞打不动。另外-p控制覆盖遍数默认 1 遍就够了设成 3 遍除了把清零时间拉长三倍没有任何收益。执行时你会看到一条进度条在跑磁盘 IO 会明显飙高因为工具正在往每一个空闲簇里写零。这一步对业务盘要留神如果客户机磁盘本身已经用到 90% 以上空闲空间没多少跑起来很快就结束但也意味着可回收的空间本来就有限。3.2 关机与前提确认快照、锁、格式清零跑完接下来必须关机。这一步没有捷径vmkfstools -K要独占访问 vmdk虚拟机开着就报文件占用。关机指的是完整关机Guest Shutdown 或 Power Off不是挂起挂起状态下磁盘同样被持有。关机后通过 SSH 登录虚拟机所在的 ESXi 主机。ESXi 默认没开 SSH需要在主机“服务”里临时启用安全 Shell用完记得关。登录后先做三件事# 1. 进入虚拟机所在目录路径按实际数据存储名替换 cd /vmfs/volumes/datastore1/your-vm # 2. 看回收前的落盘大小记下来做对比 # 第一列是占用块数第二列是文件表观大小 ls -ls *.vmdk # 3. 检查有没有快照增量盘有 -000001 这类后缀就是还有快照 ls -1 *-0000*.vmdk 2/dev/nullls -ls这个组合比单纯ls -lh有用得多。第一列的块数明显小于“表观大小 ÷ 512”时说明这是稀疏文件也就是 Thin两列基本对得上说明是厚置备。这一步决定了后面有没有必要打洞——厚置备盘打洞不省空间纯属浪费时间。第三条命令是重点。如果目录里存在-000001.vmdk、-000002.vmdk之类的增量盘说明这台机器还挂着快照。此时你清零的零块全写进了增量盘基础盘一个字节都没变vmkfstools -K打基础盘等于白打。正确做法是先在快照管理器里删除或合并所有快照等合并任务真正结束不是进度条消失就算完再继续。3.3 在 ESXi 上执行打洞并验证确认干净之后执行回收命令。注意-K是大写含义是 punch zero把全零块还给 VMFS# 对单个 vmdk 打洞路径写完整别用相对路径 vmkfstools -K /vmfs/volumes/datastore1/your-vm/your-vm.vmdk # 一台虚拟机有多块盘时逐个处理别图省事用通配符 for d in /vmfs/volumes/datastore1/your-vm/*.vmdk; do echo processing $d vmkfstools -K $d done # 回收完成后核对落盘大小 ls -ls /vmfs/volumes/datastore1/your-vm/*.vmdk命令跑起来会打印进度百分比这个过程是从后往前扫描 vmdk、识别连续零块并释放块数越多越慢几十 GB 的盘通常要等十几分钟到半小时。中途别 CtrlC中断不会损坏数据但会留下部分回收的状态下次还得从头跑。回收完成后对比ls -ls的第一列。开头那个案例回收前 vmdk 占 36.7G打洞之后落到 27.8G 左右和客户机里的实际使用量基本对齐这就算成功了。如果数字只降了一点点八成是客户机里没跑-z、跑的时候不是管理员、或者盘上有快照——回上一节重新确认一遍。注意vmkfstools -K只处理零块。客户机里那些“看起来删了但文件系统还标记占用”的块它一概不认。所以顺序永远是先清零再打洞反过来做毫无意义。4. Storage vMotion 回收不停机把 Thin 盘瘦下来的第二种走法4.1 迁到厚置备延迟归零再迁回 Thin不能停机的时候就只能走迁移这条路。原理不难理解Storage vMotion 是整盘复制目标端的 vmdk 是按源端“实际使用了多少块”重新写出来的那些没被引用的空闲块根本不会被复制过去副本天生就是瘦的。操作步骤在 vSphere Client 里完成关键在格式选择上右键虚拟机 → 迁移 → 选择“仅更改存储”不要选“更改计算资源”避免顺带迁主机引入额外变量。选择目标数据存储确认它有足够空间。在“选择虚拟磁盘格式”里选厚置备延迟归零Thick Provision Lazy Zeroed不要选“与源格式相同”。确认后提交任务等任务真正完成。如果最终还想用 Thin再做一次迁移回到原数据存储这次格式选Thin。为什么中间要绕一次厚置备因为第一次迁移的目的是“重写”不是“瘦身”。选厚置备延迟归零目标端会按已用块完整写出跳过所有空闲块落盘即瘦。等你确认空间已经释放再迁回 Thin 拿回动态扩展的灵活性。如果第一次就选 Thin行为其实也差不多但中间格式选厚置备更容易判断“到底复制的量对不对”出问题时排查路径更清晰。第二次迁回时有个细节目标数据存储必须真的能容纳这台机器Thin 虽然不会立刻占满但数据存储剩余空间小于虚拟机已用空间时迁移会直接拒绝。4.2 硬条件目标容量、快照状态、兼容性迁移失败大多栽在这三件事上。容量算法是最容易误判的一条。厚置备延迟归零会按虚拟机的已置备容量占位不是按已使用量。一台配了 500G 盘、实际只用 100G 的虚拟机迁到目标存储需要 500G 可用空间不是 100G。报错信息通常是目标数据存储空间不足很多人第一反应是“我明明还有 200G”问题就出在这个算法差异上。解决办法要么先扩存储要么在维护窗口里先用方法一把已用空间压下去。快照状态是第二条。机器挂着快照时虚拟磁盘格式转换常常做不了任务会失败或者干脆不给选格式。判断方法还是看目录里有没有-0000xx.vmdk。有的话先在快照管理器里合并合并任务在大盘上可能跑很久别看着进度条走完就以为结束要去任务列表确认状态是“已完成”。兼容性排在第三。跨不同 CPU 架构的 ESXi 主机做迁移可能触发兼容性检查失败虚拟机的虚拟硬件版本太老某些格式转换也不支持。稳妥的做法是先在当前主机内部换数据存储同主机、不同 datastore避开计算资源的兼容性问题等格式转换完成再考虑跨主机。4.3 代价它不便宜别当成日常操作Storage vMotion 好用但代价得算清楚。它是全量复制源端要读、目标端要写、网络上要传三份资源同时吃。一台 1TB 的虚拟机在普通千兆环境里跑几个小时很正常这段时间存储阵列的 IO 压力会明显上升跑在同一个数据存储上的其他业务可能跟着变慢。更关键的是它不可逆地消耗了一次“全量拷贝”的额度。你今天迁一次瘦下来过两个月客户机里又删了一堆文件还得再迁一次。反复迁的成本比停机做一次vmkfstools -K高得多。我的习惯是有维护窗口就老老实实用方法一把 vMotion 留给“必须在线”和“顺便要换存储”这两种场景。5. 避坑清单五种让回收当场翻车的情况5.1 vmkfstools 报文件被占用现象执行vmkfstools -K立刻报错退出提示无法打开磁盘、文件正在使用速度快到像是根本没开始跑。原因虚拟机没真正关机或者虽然关了但还有残留进程持有 vmdk最常见的是挂起状态、备份软件正在做快照、或者另一台 ESXi 主机上的控制台还连着。解决先确认虚拟机电源状态是“已关闭”而不是“已挂起”把 vSphere Client 和远程控制台全部断开等一两分钟让锁释放再重试。仍然报错就去任务列表里看有没有没跑完的克隆或迁移任务那类任务会长期持有磁盘锁必须等它结束或者取消掉。5.2 SDelete 跑完vmdk 反而更大了现象客户机里清零顺利完成回头一看 vmdk 比之前还大几个 G存储用量不降反升。原因三种可能。一是这台机器还挂着快照零块全写进了增量盘增量盘暴涨二是盘的格式本来就是厚置备写零等于在已经占满的区域又写了一遍三是用了-c而不是-z随机数据不构成连续零块自然打不出洞。解决先看目录里有没有-0000xx.vmdk有就合并快照再用ls -ls判断是不是厚置备如果是先做一次 Storage vMotion 转成 Thin 再谈回收最后确认命令里用的是-z。三条都排除才考虑是不是客户机文件系统本身有大量保留块比如启用了去重的存储卷那种情况清零效果会打折。5.3 Storage vMotion 报目标空间不足但明明还剩很多现象迁移任务刚开始就失败提示目标数据存储空间不够可你在 Client 里看剩余空间还有一大截。原因厚置备延迟归零按已置备容量占位。你的 Thin 盘实际只用了 100G但虚拟磁盘配置是 500G目标端就要 500G 可用空间。Client 显示的“剩余空间”扣掉的是实际占用两者口径不一样。解决要么把虚拟磁盘容量调小需要客户机内先缩分区风险高要么先把已用空间压一压要么换一块更大的目标存储。实在没办法就只能回到方法一用停机窗口打洞它不需要第二块存储。5.4 回收显示成功数据存储用量却没变现象vmkfstools -K跑完没报错ls -ls看 vmdk 也确实变小了但数据存储的整体使用率一点没降告警还在。原因数据存储里除了这台机器还有别的空间占用——快照增量盘、虚拟机交换文件.vswp、日志、以及别的虚拟机。另外 Client 界面有刷新延迟指标不是实时的。解决在 ESXi Shell 里进数据存储根目录用du -h -d 1 .看各个虚拟机目录的实际占用一眼就能定位是谁在吃空间。确认是别的对象占的就别在这台机器上继续折腾了。如果是界面没刷新退出重新登录即可。5.5 Linux 客户机上用 fstrim 完全无效现象客户机是 Linux跑了fstrim -av显示成功甚至提示释放了多少字节回到 ESXi 一看 vmdk 没缩。原因还是 vmfs5 那条链路的问题。客户机发出的 TRIM 请求在 vmfs5 上不往下传命令返回成功只代表客户机侧执行完了下层没收到任何东西。解决Linux 上的等价做法是把空闲空间写成零文件再删掉比如dd if/dev/zero of/zero.fill bs1M写满后rm -f /zero.fill然后关机走vmkfstools -K。ext3/ext4 还可以用zerofree但必须把文件系统重新挂载为只读才能跑生产机上要安排好窗口。两种方式效果一样选顺手的那条。6. 快速定位五步确认这块 Thin 盘到底瘦没瘦被“空间到底回收了没有”反复折磨过几次之后我固化了一套五分钟能走完的确认流程按顺序做基本不会误判。第一步看客户机侧。进虚拟机看磁盘实际使用量记下这个数字。它是你的目标值vmdk 落盘大小最终应该贴近它而不是贴近已置备容量。第二步看 vmdk 落盘大小和格式。SSH 进 ESXicd到虚拟机目录跑ls -ls *.vmdk。第一列是块数明显小于表观大小说明是 Thin两列接近就是厚置备厚置备盘不用考虑打洞。第三步查快照。ls -1 *-0000*.vmdk 2/dev/null有任何输出说明还有增量盘先合并快照再做别的否则后面全是无用功。第四步查数据存储整体占用。在数据存储根目录跑du -h -d 1 .看看空间是不是被别的虚拟机、交换文件或者日志吃掉了。这一步能挡掉至少三分之一的“回收失败”误报。第五步才动手并且在动手前后各记录一次ls -ls的结果做对比。把常见现象和排查动作对应起来这张表可以直接贴在工位上现象优先怀疑一条命令vmdk 大小完全不变客户机没清零或盘是厚置备ls -ls *.vmdk打洞报文件被占用虚拟机未真正关机 / 有任务持锁查看任务列表与电源状态打洞成功但不缩存在快照增量盘ls -1 *-0000*.vmdk清零后 vmdk 反而变大用了-c而非-z或有快照检查命令参数与快照迁移报空间不足目标按已置备容量算空间df -h对比已置备大小存储用量始终不降空间被其他对象占用du -h -d 1 .还有一个容易被忽略的验证动作回收完成后不要马上重启虚拟机先在 ESXi 侧确认 vmdk 大小稳定下来再开机进客户机检查文件系统完整性。清零过程只碰空闲块理论上不会影响数据但我确实见过有人在客户机没完全关机的情况下强行打洞结果文件系统元数据错乱最后只能从备份恢复。从那以后我每次做精简磁盘回收前都强制走一遍“关机状态确认 快照清单 回收前大小记录”这三件事哪怕再急也不省。踩过的坑告诉我这套流程里最贵的从来不是命令本身而是漏掉一个前提条件后重来的那几个小时。希望帮到你。本文还有配套的精品资源点击获取