虚拟机释放硬盘后空间未恢复，根源在于VMware的“精简置备”机制不会主动把空闲块还给存储卷，必须手动触发UNMAP回收，且前端Guest OS要先完成TRIM或清零操作。多数用户删除文件后看到可用空间没变，是因为虚拟磁盘文件（vmdk）本身没有缩小，数据块还留在里面,下面直接拆解原因和操作路径。
VMware虚拟机磁盘空间不释放，先查这三处
精简置备的“假释放”
创建虚拟机时选了“精简置备”，vmdk文件会按需增长，但删除内部文件后，vmdk不会自动缩水，这是设计如此，不是故障。vSphere中“删除文件”与“回收空间”是两码事：前者只清Guest OS里文件系统的记录,后者才涉及把数据块归还给VMFS数据存储。
快照把旧数据“冻结”了
如果虚拟机挂着快照，所有被删除的数据块仍然保留在快照链中，此时做任何回收操作都无效，因为存储层认为那些块还属于活跃快照。必须先删除或合并快照，再谈空间回收，快照是导致space not reclaimed的高频原因,排查时优先排除。
Guest OS没有配合TRIM
虚拟机里的Windows或Linux删除文件后，文件系统层面只是标记了可写状态，底层块设备不知道哪些块可以丢弃，Windows Server 2012以上需要手动“优化驱动器”触发TRIM，Linux需要运行fstrim。没有这一步，vSphere的UNMAP拿到的是“空请求”,自然无法回收。
ESXi精简磁盘空间不回收，手动UNMAP怎么操作
确认版本和条件
ESXi 6.5之后支持自动UNMAP，但默认配置相当保守，需要手动干预，行业共识认为，vSphere 7.0及以后版本对UNMAP的响应机制更积极，但依旧推荐主动执行,同时满足以下条件才有回收效果：
- 虚拟磁盘是精简置备，非厚置备惰性清零
- Guest OS已完成TRIM或fstrim
- 快照已删除
- 存储阵列支持SCSI UNMAP命令（现代存储基本都支持）
ESXi命令行实际执行路径
SSH登录ESXi主机,先看数据存储当前的未映射空间：
esxcli storage vmfs unmap --volume-label=datastore1 --reclaim-unit=200
--reclaim-unit单位是MB，200代表单次回收200MB，数值越大单次扫描越久，如果数据存储较大，建议分多次跑，避免存储IO飙高,查询当前UNMAP状态：
esxcli storage vmfs unmap -l
若显示“Unmap not supported”或者无输出变化，检查存储阵列的VAAI插件是否启用，老版本vSphere（6.0之前）只支持全量UNMAP，跑起来很慢,新版本支持增量回收。
图形界面替代方案
vCenter里选中数据存储，“操作”菜单里没有直接的UNMAP按钮（vSphere 8.0依然如此），需要靠命令行，但如果用的是vSAN或VMFS 6，建议直接升级到ESXi 7.0 U2以上，自动UNMAP会在后台周期性执行,多数情况下可以等待系统自行回收。
Windows虚拟机删除文件后磁盘不减，优化卷这一步很关键
先理解为什么Windows虚拟机的磁盘空间看起来没变化。NTFS文件系统删除文件后，空闲空间只是标记为可覆盖，不会向存储层发起TRIM，必须手动告诉Hyper-V或VMware“这些块没用了”。
具体操作步骤（以Windows Server 2019为例）：
- 打开“此电脑”，右键点击系统盘（通常是C盘）
- 选择“属性” → “工具” → “优化”
- 点击“优化”按钮，等待碎片整理工具运行
- 若磁盘类型显示为“固态硬盘”，说明TRIM已生效；若显示“硬盘驱动器”，可能需要考虑卸载并重新附加虚拟磁盘，或者检查IDE vs SCSI控制器类型
SCSI虚拟控制器比IDE更容易传递TRIM命令，如果虚拟机用IDE启动，即便做了优化卷操作，VMware也接收不到正确的UNMAP信号，改为PVSCSI或LSI Logic SAS控制器,往往能解决Windows虚拟机空间不释放的问题。
Linux虚拟机执行以下命令后,再去ESXi层跑UNMAP：
fstrim -av
如果系统里fstrim命令不存在，用mount -o discard,remount /临时开启持续丢弃模式，分析Linux内核版本时，建议优先使用blkdiscard对特定分区做批量操作,速度更快。
快照与克隆导致的虚拟磁盘占用虚高
快照删除后的空间延迟回流
快照合并完成后，vmdk的子文件（-delta.vmdk）被整合到基础磁盘，但存储层的回收需要重新触发UNMAP，很多用户删除快照后发现数据存储空间没有恢复，误以为操作失败,实际上只是缺少了最后一步。
用vmkfstools -y可以强制回收快照合并产生的未用空间：
vmkfstools -y 百分比 虚拟机.vmdk
这个命令在合并快照后立即执行,能有效避免空间长期悬空。
克隆虚拟机的底层存储放大
完全相同克隆（Linked Clone）依赖父vmdk的快照链，删除子虚拟机只删除了增量文件，父vmdk的空间占用仍被其他子VM引用。即使看到状态显示“已删除”，实际存储释放可能被链式引用锁定
，这类场景下，要检查的是“容器虚拟机”是否还存在,而不是纠结单个VM的vmdk大小。
不同存储环境下的UNMAP表现差异
拿实际环境对比说明,回收成功率主要取决于存储层：
| 存储类型 | 自动UNMAP支持 | 手动回收效果 | 注意事项 |
|---|---|---|---|
| 本地SATA/NVMe | 部分支持 | 较好 | 需要确认SSD固件支持TRIM |
| 中端SAN（如HP、Dell） | 多数支持 | 良好 | 依赖VAAI 插件版本 |
| 分布式存储（如vSAN） | 原生支持 | 优秀 | 默认自动回收，无需手动 |
| NFS挂载 | 不支持 | 无效 | 只能用瘦客户端清理内部碎片 |
NFS数据存储的场景下，空间回收在ESXi层完全不可控，必须转向NAS侧的快照清理或文件级清理，业内专家指出，很多“虚拟机释放硬盘后空间未恢复”的求助帖，其底层是NFS挂载或老旧的SMB共享存储,体系结构上就无法实现UNMAP。
虚拟机扩容后空间未恢复与预算方向的延展
扩容反向操作时容易踩坑
用户把虚拟磁盘从100GB扩到200GB后，再删除内部文件腾出空间，vmdk文件大小依旧接近200GB，这是精简置备的另一种表现形式：扩容后的vmdk元数据已更新，但已使用的块数不变，此时没有特殊命令能“缩回”vmdk头部记录的大小，只能靠重新做虚拟机迁移或使用第三方工具收缩，经常有人疑惑“vmware虚拟机磁盘空间不释放是否和扩容有关”，答案更多是扩容暴露了原有增长机制,并非扩容本身导致堵塞。
涉及的费用与硬件选购考量
如果按年付费的vSphere许可包含“存储I/O控制”和“空间回收”模块，建议直接启用，采购时，市场上支持VAAI UNMAP的阵列价格差异巨大，企业级全闪存阵列的回收效率和耐用性明显优于机械盘阵列。若预算吃紧，可以先跑几轮手动UNMAP观察释放量，再决定是否增加存储，每次手动回收能释放的容量取决于Guest OS使用率和快照策略，无法预先给出固定比例,实际测试是最可靠的方式。
单次执行后仍未恢复的彻底排查路径
逐层验证操作顺序
- 在Guest OS里运行优化（Windows）或fstrim（Linux）
- 确认虚拟磁盘控制器是Paravirtual SCSI
- 关闭vCenter中关于该VM的Storage DRS自动化级别
- SSH登录ESXi执行
esxcli storage vmfs unmap --volume-label=datastore1 --reclaim-unit=500 - 等待5-10分钟后用
df -h或vSphere客户端查看数据存储已用空间
如果以上步骤全部完成但空间依旧没变化，大概率是存储阵列固件的UNMAP处理有bug。升级存储固件后，再跑一轮上述命令，多数情况能解决，同时检查ESXi主机的“VMFS 6”版本标记，老版本VMFS 5对UNMAP的块大小对齐要求更严格,格式化时建议选择1MB的块粒度。
避免症状复发的日常设置
- 对频繁删除数据的虚拟机，开启“精简置备”并配合每月一次的UNMAP计划任务
- 快照保留时间不要超过3天，快照链越长空间回收越困难
- 在监控中关注“未映射空间”指标，而不是只看已用空间百分比
流程跑完后，回到现实层面：虚拟机的存储空间管理本质上是“前端回收+后端映射”的协作，前端操作系统没有丢弃数据块，后端再用力也是空转，虚拟机释放硬盘后空间没恢复，不是无解的问题，排查顺序多数情况下就是“Guest OS先清理，快照先合并，存储再回收”，按照这个逻辑操作,能解决绝大部分场景下的空间浪费。
虚拟机磁盘空间不释放常见问题排查
问：虚拟机内部显示磁盘已删除了大量文件，但vSphere里vmdk文件大小完全没变，是哪里出错了？
答：vmdk文件大小代表虚拟机“曾经写到过的最高水位”，内部删除文件只会产生空闲块，不会修改vmdk的容量记录，需要执行UNMAP操作后，vmdk的高水位才会回落，这个过程在ESXi上需要额外的回收时间,并非实时生效。
问：执行了优化驱动器和fstrim，也删除了所有快照，为什么数据存储空间还是没变化？
答：可能是因为存储阵列不支持自动TRIM穿透，或者ESXi主机的自动UNMAP默认周期尚未到达，手动在ESXi命令行执行一次带较大--reclaim-unit参数的unmap操作，观察数据存储空间是否有变化，如果依旧未变化,需要确认存储设备的VAAI状态是否存在异常。
问：把虚拟磁盘格式从精简置备转换为厚置备后，是否就能释放空间？
答：不能，厚置备惰性清零反而会预占更大的物理存储空间，转换过程不会自动回收已删除的块，厚置备只是改变了分配策略，并没有改变Guest OS文件系统层面的空闲块状态，相反,精简置备配合UNMAP才是更友好的空间使用方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623049.html
