删除VMware虚拟机后datastore空间不释放，根源在于vmdk文件未被彻底删除或虚拟磁盘仍以快照形式占用存储，最直接的解决路径是登录存储浏览器手动清理残留文件，再执行unmap命令完成空间回收。
VMware删除虚拟机后空间没释放？问题出在三个常见环节
很多管理员在vSphere Client里右键删掉虚拟机，回头一看数据存储的可用容量几乎没变，这不是系统卡了，而是有几个环节把数据“留了一手”。
快照文件（delta.vmdk）被遗漏删除
删除虚拟机时,如果该虚拟机存在快照，vCenter通常会将虚拟机记录移除，但快照产生的delta.vmdk文件可能残留在datastore目录中，这些差量文件可能相当大，尤其是快照存在时间较长、期间虚拟机写入量大的场景。
排查方式很直接：进入vSphere Client → 存储 → 选中对应datastore → 点击“文件”选项卡，查看该虚拟机目录下是否还有-snapshot1.vmdk、-delta.vmdk等子文件，如果有，手动选中删除即可。
虚拟磁盘精简置备和厚置备区别：回收机制差异
这是最常见也最容易混淆的场景,虚拟磁盘有两种主流格式：
- 厚置备（Thick Provision）：创建时一次性占用全部空间，删除虚拟机后，这部分空间在VMFS文件系统中不会自动标记为可回收，需要手动处理。
- 精简置备（Thin Provision）：按需增长，但VMFS文件系统删除文件后不会自动向存储控制器发送TRIM或UNMAP指令，空间依然显示为已占用，必须手动触发回收命令。
行业共识认为,精简置备磁盘在VMFS文件系统上的空间回收一直是运维盲点，多数情况下需要人工干预，不能指望删除操作自动完成空间释放。
回收站或备份软件的“伪删除”
部分企业环境中部署了Veeam、CommVault等备份软件，虚拟机删除操作会触发备份保留策略，导致vmdk文件被转移到备份存储中，源datastore空间自然不释放，如果启用了vSphere的回收站功能（部分第三方工具提供），删除操作实际上只是把文件标记为隐藏，空间并未真正释放。
手动清理datastore残余文件并执行unmap回收：完整命令流程
清理工作分为两步：先清文件，再回收空间，只做第一步，空间占用数字可能依然不变。
通过Web客户端操作清理残留文件
打开vSphere Client → 存储 → 选择datastore → 文件浏览器 → 找到已删除虚拟机的目录：
- 若目录为空壳但有.vmx或.vmdk文件，直接删除。
- 若目录中仍有虚拟磁盘文件但体积为0,说明是元数据残留，可删除。
- 若存在>0MB的vmdk文件，先用SSH登录ESXi检查是否有进程占用该文件。
使用esxcli命令回收VMFS文件系统空间
SSH登录ESXi主机,执行以下命令：
esxcli storage vmfs unmap -l datastore名称参数说明：
-l：指定数据存储名称，需用单引号括起来避免空格影响。-u：可选参数，指定要回收的VMFS卷UUID。-n：可选，指定回收块数量，一般家用或小型环境不需要。
执行过程中会看到“Checking for released blocks”等提示信息。unmap执行时间和datastore容量直接相关，上百TB的存储可能需要数小时，建议在业务低峰期执行。
NFS与VMFS卷回收方式不同
NFS数据存储的情况完全不同,因为空间管理逻辑在NAS端。NFS存储上删除虚拟机后空间未释放，需要在NAS设备端检查文件系统是否支持块回收，例如NetApp的自动快照策略、QNAP的回收站功能，都可能把删除文件保留一段时间，ESXi上的unmap命令对NFS卷不起作用。
空间回收后容量没有变化怎么办
执行完unmap,datastore可用空间依然没变化，通常有两种可能：
- datastore中仍有其他大文件占用空间,检查.iso文件、旧的swap文件等。
- VMFS卷存在控制文件碎片,需要重启ESXi主机或使用VMware KB推荐的Storage vMotion方式迁移数据后重建存储卷。
SSDs与HDD混合存储场景下的空间回收差异
在实际生产环境中,全闪存阵列和机械硬盘混布方案的空间回收表现有明显差异，运维策略需要相应调整。
全闪存阵列：自动回收依赖存储端策略
全闪存阵列通常支持高效的垃圾回收机制,如果存储端启用了自动tirm/UNMAP调度，ESXi执行unmap后，空间会较快反映在存储管理界面中。行业专家指出，全闪存场景下建议在存储侧开启自动空间回收调度，不需要等待ESXi端手动执行，可以将回收周期设置为每日或每周。
机械硬盘阵列：unmap执行时间更长
机械硬盘在物理寻道和写入放大机制上存在天然劣势,执行unmap时，存储控制器需要对大量块做重新映射，耗时较长且可能影响IO性能，建议在夜间或维护窗口执行，并分批次处理多个数据存储。
混合存储环境下的容量视图
在VMware环境中,存储容量存在两层视图：ESXi层看到的容量和存储阵列管理界面看到的容量，删除虚拟机后，ESXi层可能已经显示空间释放，但存储端仍然显示容量占用，这是因为存储端的LUN映射关系尚未更新，此时需要在存储阵列上执行LUN级别的空间回收操作，或者等待存储端的自动回收策略生效。
日常避免datastore空间被占用的两个习惯
临时处理解决眼前问题,但治本需要养成以下操作习惯，能明显减少“删完不释放”的事件发生。
使用vSphere Web Client的“从磁盘中删除”选项
删除虚拟机时,vCenter会弹出两个选项：从清单中移除、从磁盘中删除，选择“从磁盘中删除”会尝试删除所有关联文件，包括快照和日志，在实际操作中，如果虚拟机存在故障或锁定状态，该选项可能失效，因此需在删除前确认虚拟机状态。
定期执行Storage vMotion迁移重建空间
对于长期运行、频繁创建和删除虚拟机的环境，建议定期对datastore做碎片整理，方法是将虚拟机在线迁移到另一个datastore，再迁移回来，这会迫使VMFS重新审视已释放的块，在精简置备场景下效果显著。
创建虚拟机时合理选择磁盘置备模式：
- 测试环境优先使用精简置备,避免浪费初始空间。
- 生产环境数据库虚拟机,考虑厚置备开销，但需配合定期回收任务。
- 避免频繁对大型虚拟机创建和删除快照,快照链是空间占用的隐形杀手。
上海VMware虚拟化部署优化中遇到的空间回收问题
在华东地区企业级VMware实施中,空间回收问题是运维团队关注频率最高的议题之一，上海地区不少金融、制造企业使用VMware vSphere构建私有云，由于业务系统数量大、虚拟机变动频繁，空间回收的问题在VMware虚拟化部署优化中往往被低估。
部分企业在选择VMware服务商时,关注价格但忽略后续运维能力的评估，实际上datastore空间回收涉及存储底层协议、文件系统机制、虚拟磁盘格式等多层知识，需要具备经验的工程师进行现场排查，据行业信息，上海虚拟化实施服务商的报价区间差异较大，但空间回收属于基础运维场景，一般包含在年度维保服务中，如按单次计费，多数情况下在数千元级别，具体取决于数据存储容量和问题复杂度。
从长期运维角度看,建立月度datastore空间巡检机制，形成容量趋势报告，比出了问题再补救更有效。
常见问题解答
VMware删除虚拟机后datastore空间不释放，重启ESXi能解决吗？
重启ESXi主机通常无法解决空间不释放的问题,因为VMFS文件系统的元数据在重启后依然保留原有分配状态，只有在确认该数据存储无虚拟机运行、且已删除虚拟机文件的情况下，执行esxcli storage vmfs unmap命令才能触发空间回收。
精简置备的虚拟机删除后，空间会自动释放吗？
不会自动释放,VMFS文件系统在删除虚拟磁盘文件后，只是将文件标记为已删除，但LUN上的块映射不会主动更新，需要手动执行unmap命令或者执行Storage vMotion迁移，存储阵列才会感知到这些块可以被覆写或回收。
NFS数据存储上删了虚拟机，空间没释放，如何处理？
NFS数据存储上的空间回收与VMFS机制不同,ESXi执行unmap命令对NFS卷无效，需要登录NAS设备管理界面，检查该共享目录是否存在回收站策略或快照残留，若均无异常，则需在NAS文件系统层面执行碎片整理或扩容操作。