简介这份文档面向使用 VMware 虚拟化平台、受精简置备磁盘“占而不放”问题困扰的运维人员与虚拟化学习者聚焦 vmfs5 文件系统不支持自动回收空间这一常见痛点给出可落地的空间回收思路。包内仅含 1 个 docx 文件压缩包约 408KB篇幅精炼、便于随查随用。文档以实际案例切入先描述磁盘实际使用 27.8G、VMDK 却占用 36.7G 的典型现象再分别讲解两条路径一是借助 SDelete 的 sdelete64.exe –z 清空空闲空间随后关机并通过 SSH 登录 ESXi 主机执行 vmkfstools –K 回收二是通过 Storage VMotion 在线迁移先将磁盘转为厚置备延迟归零再迁回并选回 Thin 格式兼顾不停机场景。文档还补充了 Thin 格式的优缺点、精简卷管理与 ESXi 存储功能说明配有操作界面截图与进度示意便于对照排查、快速复现。目前已有 2021 人学习下载适合需要处理存储容量告警、优化虚拟磁盘占用的读者参考。1. 从 36.7G 的 VMDK 说起Thin 卷删了文件为什么还不掉空间一台 Windows Server 2012 R2 虚拟机Guest 里看 C 盘实际只用了 27.8G数据存储上的 VMDK 却占着 36.7G。文件确实删了回收站也清了VMDK 就是不掉。这不是系统抽风而是 VMware 精简磁盘空间回收里最典型的一幕Thin 卷按块分配Guest 删除文件只改文件系统元数据VMFS 并不知道哪些块已经变成空洞。这份文档把两条回收路线写在一起一条是停机后用 SDelete 零填充再执行vmkfstools -K另一条是在线用 Storage vMotion 换磁盘格式把空洞挤掉。适合手里有 Thin 卷、数据存储余量告急、又必须把停机窗口算清楚的运维人员。先别急着敲命令下面把三条链路拆开再落到可复现的步骤和踩坑点。2. 三条链路的判断Guest 空闲块、VMFS 块与 VMDK 粒度2.1 删除文件只改了 Guest 的元数据Guest 文件系统删除文件时通常只把索引项标记为空闲数据块内容还在。对物理机来说这不算大问题新文件会覆盖旧块对 Thin 虚拟磁盘来说问题被放大VMDK 只知道“这个块曾经写过”不知道 Guest 已经把它标成空闲。于是 Guest 里空间越用越少VMDK 却只增不减。SDelete 的-z参数做的事很直接把 Guest 逻辑卷上的空闲块全部写成零。零块在后续vmkfstools -K扫描时可以被识别并收缩Thin 磁盘才有机会把“写过但已空闲”的块还回去。这里的关键不是清理文件而是把 Guest 的空闲状态翻译成 VMFS 能看懂的零块。2.2 vmfs5 的手动回收缺口在哪里这套环境里的 vmfs5 文件系统没有把自动回收跑通。Guest 删除文件后VMFS 块不会立刻变成可复用空间数据存储余量自然对不上。手动回收分两段第一段在 Guest 内把空闲块零化第二段在 ESXi 层对 VMDK 做收缩。缺少任何一段VMDK 都可能只瘦一点或者完全不动。原料里给的vmkfstools –K *.vmdk是第二段的命令但它有前提虚拟机关机、快照合并干净、目标 VMDK 是基础盘而不是快照盘。现场最容易翻车的地方就是把通配符当成省事写法结果把-000001.vmdk之类的快照盘也带进去。2.3 选停机零填充还是在线迁移两条路线不是谁替代谁而是按停机窗口和目标存储余量选。SDelete 加vmkfstools -K的优点是回收直接、不需要额外数据存储缺点是必须停机而且零填充会吃 CPU 和磁盘 IO大磁盘要留足时间。Storage vMotion 的优点是可以在线迁移VM 不停机缺点是目标存储必须能放下迁移后的磁盘第一跳选厚置备延迟归零时目标会按最大容量分配容量不够就直接卡住。常见做法是能接受停机、目标存储紧张走方法一不能停机、有第二块数据存储走方法二。要是目标存储只剩一点余量别硬上 Storage vMotion先清空间或者加临时存储。2.4 动手前的四条检查命令维护窗口开始前先上 ESXi 主机把虚拟机 ID、快照、VMDK 实际占用和数据存储余量查一遍。下面几条命令是我一般在 SSH 里先跑的目的不是炫技而是避免后面把快照盘当基础盘收缩。# 列出虚拟机并找到目标 VM 的 vmid vim-cmd vmsvc/getallvms | grep -i VM01 # 查目标 VM 的快照输出为空才适合做收缩 vim-cmd vmsvc/get.snapshotinfo vmid # 看目标目录下 VMDK 的实际占用和文件名 cd /vmfs/volumes/datastore1/VM01 ls -lsh *.vmdk # 看数据存储余量回收前先留出安全余量 df -h /vmfs/volumes/datastore1vim-cmd vmsvc/getallvms用来拿 vmid后面的快照查询要用它get.snapshotinfo输出为空说明没有快照有快照先合并不要直接收缩。ls -lsh里第一列是实际占用别只看文件逻辑大小df -h看的是数据存储余量回收前至少留出一成以上的安全空间。Guest 内也要确认磁盘使用量Windows 下用Get-PSDrive C看已用空间Linux 下用df -h。这四条检查不做后面很容易出现“命令跑完了但 VMDK 没变”的假故障。3. 方法一落地SDelete 零填充加 vmkfstools -K 的停机回收3.1 维护窗口里先确认四件事方法一不是上来就敲sdelete64.exe。先把四件事确认掉Guest 内没有正在跑的大批量写入Windows 更新和备份任务已经停掉虚拟机没有快照快照盘和基础盘不要混在一起数据存储余量足够支撑收缩过程中的临时 IO停机窗口覆盖零填充和vmkfstools -K两段时间。原料里那台机器 Guest 实际用了 27.8GVMDK 占了 36.7G差额接近 9G这种量级在小盘上不算大但零填充仍然会扫全盘空闲块盘越大越要留时间。我一般会把 SDelete 放在维护窗口前半段跑跑完立刻关机做 ESXi 层收缩避免中间又产生新写入。3.2 SDelete 的参数与执行观察把sdelete64.exe放到 C 盘根目录用管理员权限打开 CMD。原料里给的命令是sdelete64.exe –z C:注意这里是大写盘符加冒号-z表示零化空闲空间不是删除文件。执行后会出现进度条进度条走完不代表 VMDK 立刻变小它只完成了 Guest 侧的空闲块零化。:: 以管理员身份打开 CMD 后执行 :: -z 零化空闲空间C: 是目标卷多分区环境要按实际卷逐个处理 C:\sdelete64.exe -z C:参数说明-z是零化空闲块专门为虚拟磁盘收缩场景准备C:是 Guest 内要处理的卷。测试环境只有一个分区所以只跑 C 盘生产环境如果有 D、E 盘要按实际卷分别执行否则未处理卷的空洞还在。执行期间不要中断也不要同时跑磁盘碎片整理。SDelete 跑完后Guest 内空闲空间内容已经变成零块但 VMDK 还是原样接下来必须关机。3.3 关机后定位 VMDK 并执行 vmkfstools -K虚拟机关机后通过 SSH 登录 ESXi 主机进入虚拟机目录。原料里写的是vmkfstools –K *.vmdk我建议先把*.vmdk列出来确认只对基础盘执行不要对快照盘执行。下面命令里VM01.vmdk要换成实际基础盘文件名带空格的路径要加引号。# 进入虚拟机目录路径按实际数据存储和 VM 目录调整 cd /vmfs/volumes/datastore1/VM01 # 先列清楚有哪些 vmdk确认哪个是基础盘哪些是快照盘 ls -lh *.vmdk # 只对基础盘执行收缩-K 用于收缩 Thin 虚拟磁盘 vmkfstools -K VM01.vmdkvmkfstools -K的参数含义是收缩 Thin 虚拟磁盘执行时会扫描 VMDK 里的零块并释放对应 VMFS 块。它要求虚拟机关机执行时间跟磁盘大小和零块比例有关进度到 100% 才算完成。原料里用*.vmdk通配符现场最好别这么干快照盘、裸设备映射盘、独立盘混在一起时通配符会把不该动的文件带进去。血泪经验是先在ls -lh输出里认准基础盘文件名再单独执行。执行过程中不要开 vSphere Client 对这台 VM 做迁移或改配置等命令返回后再动。3.4 回收后的三个验证动作回收完成后别只看一眼 VMDK 数字就收工。先看 VMDK 实际占用有没有下降再看数据存储余量有没有回来最后进 Guest 确认文件系统正常。下面三条命令分别对应这三个动作。# 看 VMDK 实际占用是否下降 ls -lsh /vmfs/volumes/datastore1/VM01/VM01.vmdk # 看数据存储余量是否回来 df -h /vmfs/volumes/datastore1 # 看虚拟机是否还在关机状态确认后再开机 vim-cmd vmsvc/power.getstate vmidls -lsh的第一列是实际占用和回收前对比才有意义df -h看数据存储余量注意 VMFS 的余量刷新可能有延迟等几秒再看power.getstate确认 VM 状态确认无误再开机。开机后进 Guest 看磁盘管理确认卷没有异常再跑一遍业务检查。方法一的边界很清楚必须停机零填充会扫全盘大磁盘要留足窗口但它的好处是不依赖第二块数据存储回收链路短适合余量紧张的环境。4. 方法二落地Storage vMotion 换格式的两跳回收4.1 第一跳把 Thin 迁到厚置备延迟归零方法二的核心不是“迁移”两个字而是借迁移换磁盘格式。第一跳把 Thin 磁盘迁到厚置备延迟归零迁移过程中虚拟磁盘会被重新写一遍原来 Thin 里的空洞在目标端不再以精简块的形式保留旧数据存储上的 VMDK 在迁移完成后释放。原料里强调目标存储要有足够空间这一点必须放在第一位厚置备延迟归零会按磁盘最大容量分配目标空间不是按当前实际使用量分配。也就是说源端 VMDK 虽然只占 36.7G目标端可能要按磁盘最大容量准备空间容量不够时迁移会直接失败。迁移可以在线做VM 不需要停机但迁移期间对源端和目标端的 IO 都有压力业务高峰期别硬上。4.2 在线迁移的操作路径与参数在 vSphere Client 里选中虚拟机右键迁移选择“更改数据存储”目标存储选第二块数据存储虚拟磁盘格式选“厚置备延迟归零”。这一步的关键参数只有两个目标数据存储和磁盘格式。目标存储要确认余量大于磁盘最大容量不要只看当前 VMDK 占用磁盘格式要选厚置备延迟归零不要选 Thin否则第一跳没有意义。迁移任务开始在任务栏里能看到进度迁移完成后原数据存储上的 VMDK 会释放但目标端变成厚置备延迟归零占用会按最大容量算。下面这张表是我现场用来做格式选择的不是理论分类而是回收场景下的取舍。磁盘格式空间分配方式回收场景下的作用主要代价Thin按需分配日常省空间但空洞不会自动还需要手动回收VMDK 可能虚胖厚置备延迟归零创建时分配全部块零化延迟第一跳把空洞挤掉迁移完成释放旧存储目标端按最大容量占空间容量要求高厚置备立即归零创建时分配并立即零化性能稳定适合对 IO 敏感的盘占用最大迁移时间更长选厚置备延迟归零而不是立即归零是因为第一跳的目标只是把旧存储的空洞释放掉延迟归零在迁移场景下够用目标端零化压力比立即归零小。迁移完成后先别急着做第二跳确认虚拟机运行正常、目标存储余量还在安全线以上再做迁回。4.3 第二跳迁回 Thin 并把容量账算清如果还想继续用 Thin需要再做一次 Storage vMotion把虚拟机从厚置备延迟归零迁回原来的数据存储磁盘格式选 Thin。第二跳完成后新 Thin 磁盘只分配实际有效块空洞不再被分配空间才算真正回收。这里有一个容量账要算清楚第一跳目标端按最大容量占空间第二跳源端是厚置备延迟归零目标端是原数据存储的 Thin。两跳之间目标存储的余量要分别满足不能拿第一跳的余量去套第二跳。原料里写“完成后磁盘格式转换为厚置备延迟归零如果还想用 Thin再迁回来”这个顺序不能反先厚后 Thin才能把空洞留在旧存储上释放掉。第二跳完成后原数据存储的 Thin 占用会明显下降但迁移过程仍然需要目标存储有足够空间承接厚置备磁盘的复制流量。4.4 目标容量和迁移窗口怎么估迁移前我一般按三个数估容量源 VMDK 当前实际占用、磁盘最大容量、目标存储现有余量。第一跳目标端按最大容量分配所以目标余量必须大于磁盘最大容量再加一成安全余量第二跳目标端是 Thin按实际有效块分配余量要求低一些但迁移过程中仍然要有临时 IO 空间。迁移窗口按数据量和存储带宽估在线迁移虽然不停机但迁移期间业务 IO 会变慢数据库类虚拟机最好放在低峰期。原料里那台机器盘不大两跳都能在较短时间内完成如果是几 TB 的盘第一跳的厚置备分配和第二跳的 Thin 复制都要留足时间别把两跳塞进同一个十分钟窗口。方法二的优点是 VM 不停机缺点是目标存储容量要求高、两跳操作多适合有第二块数据存储且能接受迁移期间性能波动的场景。5. 避坑与排查五个现场翻车点5.1 现象SDelete 跑完VMDK 一点没瘦现象很常见Guest 里进度条走完了回到数据存储一看VMDK 还是 36.7G甚至因为新写入还涨了一点。原因通常不是 SDelete 没跑而是第二段没做虚拟机关机后没有执行vmkfstools -K或者执行时虚拟机还在运行命令直接失败但被忽略。还有一种情况是快照没合并基础盘被快照链挡住收缩命令作用不到真正的数据块。解决顺序是先查快照有快照先合并再关机再进目录确认基础盘文件名最后单独执行vmkfstools -K。执行完用ls -lsh对比实际占用不要只看 vSphere Client 的摘要数字。5.2 现象vmkfstools -K 报找不到文件或无法打开这个报错多半是路径和文件名的问题。ESXi 的目录名、数据存储名、VMDK 文件名里可能有空格或特殊字符通配符展开后顺序不对也会导致命令作用到错误文件。原因还包括虚拟机没有真正关机、SSH 会话没有权限、当前目录不是虚拟机目录。解决时先pwd确认目录再ls -lh看清文件名带空格就用引号包住完整路径。不要直接复制原料里的*.vmdk一把梭先把列表打出来只对基础盘执行。如果报“Failed to open”先看虚拟机电源状态再看快照再看文件权限三件事排完再重试。5.3 现象Storage vMotion 迁到一半失败目标存储满了第一跳选厚置备延迟归零时目标端按磁盘最大容量分配不是按当前 VMDK 占用分配。很多人看源端只占 36.7G就以为目标留 40G 够用结果磁盘最大容量是 60G迁移到一半目标存储满任务失败。原因就是容量估算口径错了。解决时先看虚拟机磁盘的最大容量不是看 VMDK 当前实际占用目标存储余量要大于最大容量再加安全余量。已经失败的迁移先清理目标端的残留文件再重新评估目标存储。如果目标存储实在不够别硬做第一跳回到方法一停机回收或者先扩数据存储。5.4 现象迁回 Thin 后空间没回来反而更紧张第二跳迁回 Thin 后原数据存储的空间应该释放但有时看起来更紧张。原因可能是迁移任务还没完全结束VMFS 的块回收有延迟也可能是迁移过程中产生了新的快照或临时文件把释放出来的空间又占回去了。解决时先等任务完全结束再刷新数据存储容量然后查快照和虚拟机目录下的临时文件确认没有残留的-000001.vmdk或迁移临时盘。还有一点容易被忽略第二跳的目标端如果选错数据存储Thin 磁盘会落到另一块存储上原存储当然不会释放。迁移前把源和目标在任务摘要里核对一遍别只看虚拟机名字。5.5 现象SDelete 执行很慢窗口快结束了还没跑完SDelete 零化空闲块会扫全盘磁盘越大、空闲块越多时间越长。原因还包括 Guest 内杀毒软件实时扫描、磁盘碎片多、存储 IO 本身吃紧。解决时把 SDelete 放在维护窗口前半段提前估算时间执行前停掉不必要的扫描任务大磁盘可以按卷分批处理不要一个窗口里把所有卷都跑完。如果窗口实在不够先处理系统盘和增长最快的业务盘剩下的卷排到下一个窗口。零填充不是玄学它就是 IO 换空间窗口估算要把 IO 压力算进去不能只看进度条。6. 回收后的验收一张检查表和一条硬习惯回收做完验收别只看 VMDK 数字。下面这张表是我现在每次回收后必走的检查项五项都过再算收工。检查项看什么通过标准VMDK 实际占用ls -lsh第一列比回收前明显下降且不是只降一点数据存储余量df -h余量回到安全线以上刷新后稳定Guest 磁盘状态磁盘管理或df -h卷正常业务读写无异常快照与临时文件快照列表、VM 目录没有残留快照和迁移临时盘磁盘格式vSphere Client 磁盘属性符合预期Thin 就是 Thin厚置备就是厚置备我一般会把ls -lsh和df -h的输出顺手记在维护记录里下次再遇到同一台机器空间异常能直接对比是 Guest 增长还是空洞没回收。从那以后我每次做 Thin 卷回收都强制走一遍“快照确认、停机确认、目标容量确认、回收后验收”这四步哪怕盘再小也不省。希望帮到你。本文还有配套的精品资源点击获取