VMware虚拟机磁盘文件为何持续膨胀？

Question

为什么VMware虚拟机磁盘文件（VMDK）在删除文件后仍持续膨胀？即使 guest OS 中已清理无用数据，磁盘空间未被释放回主机，导致 VMDK 文件不断增大？该现象是否与写入模式、厚置备/薄置备配置或客户机操作系统未发送 UNMAP 命令有关？如何通过启用 SCSI UNMAP、定期执行存储回收或使用 sdelete 等工具缓解此问题？

Answer 1

一、VMware虚拟机磁盘文件（VMDK）为何在删除文件后仍持续膨胀？

在企业级虚拟化环境中，VMware ESXi平台广泛使用VMDK作为虚拟磁盘格式。然而，许多系统管理员发现：即使在客户机操作系统（Guest OS）中删除大量文件并清空回收站，VMDK文件大小依然未减小，甚至持续增长。这种现象不仅影响存储利用率，还可能导致存储资源枯竭。

1. 现象描述与初步分析

• 用户在Windows/Linux Guest OS中执行del或rm -rf命令删除数据；
• Guest OS的文件系统显示可用空间增加；
• 但宿主机上对应的VMDK文件占用的物理存储空间未减少；
• 随着时间推移，VMDK文件不断增大，尤其在频繁写入/删除场景下更为明显。

2. 根本原因剖析：从抽象到本质

该问题的核心在于“逻辑删除”与“物理释放”的脱节。以下是逐层深入的技术解析：

2.1 文件系统层级：删除 ≠ 数据擦除

当用户在Guest OS中删除一个文件时，仅是将文件系统元数据中标记为“已删除”，实际数据块仍保留在磁盘上，直到被新数据覆盖。因此，VMDK底层的数据区块并未被清除。

2.2 虚拟化层：厚置备 vs 薄置备行为差异

配置类型	初始分配	增长机制	是否支持空间回收
厚置备延迟清零（Thick Lazy Zeroed）	全量分配	不增长	否
厚置备立即清零（Thick Eager Zeroed）	全量分配+清零	不增长	否
薄置备（Thin Provisioned）	按需分配	动态增长	是（依赖UNMAP）

可见，只有薄置备磁盘具备空间回收潜力，但前提是必须触发存储回收机制。

2.3 写入模式的影响：稀疏增长与零写优化

在薄置备模式下，虚拟机每向磁盘写入新数据，VMDK会动态扩展以容纳这些写入。若写入的是“零块”（zero-filled blocks），vSphere可识别并避免实际分配存储空间（Zero Write Optimization）。然而，普通删除操作不会产生零块，故无法触发此优化。

2.4 缺失的关键环节：UNMAP命令未发送

现代文件系统（如NTFS、ext4、XFS）支持发出SCSI UNMAP或ATA TRIM指令，通知底层存储设备哪些逻辑块已不再使用。但在默认配置下，多数Guest OS并不会主动向VMware虚拟磁盘发送此类命令。

# Linux示例：检查是否启用discard
    mount | grep discard
    # 若无输出，则表示未启用TRIM支持
    

3. 解决方案路径：主动回收与预防策略

3.1 启用SCSI UNMAP支持（vSphere 6.5+）

1. 确保虚拟机硬件版本 ≥ 13；
2. 使用虚拟SCSI控制器（如LSI Logic SAS或PVSCSI）；
3. 在.vmx配置文件中添加：

   scsi#.virtualSSD = 1
   disk.EnableUUID = "TRUE"
   sched.unmap.enabled = "TRUE"

4. 重启虚拟机使设置生效。

3.2 在客户机中启用TRIM/discard支持

对于Linux系统，在/etc/fstab中为ext4/XFS挂载点添加discard选项：

UUID=xxxx-xxxx / ext4 defaults,discard 0 1

Windows系统可通过defrag C: /L /X手动整理并释放空间，或部署sdelete工具。

3.3 使用sdelete等工具预清理未使用块

Sysinternals的sdelete工具可强制将未使用空间填充为零：

sdelete -z C:

执行后配合Storage vMotion或Snapshot consolidation，可促使ESXi回收零块空间。

3.4 定期执行存储回收（Space Reclamation）

vSphere提供Reclaim Unused Space功能（适用于thin disk）：

• 右键虚拟机 → Edit Settings → Hard Disk → Reclaim Blocks；
• 或通过PowerCLI批量处理：

Get-HardDisk -VM MyVM | Invoke-HardDiskSpaceReclamation

3.5 架构级建议：结合自动化运维

构建定期维护任务，例如：

• 每周执行一次sdelete或fstrim；
• 每月触发一次Storage vMotion迁移以压缩VMDK；
• 监控Datastore使用率，预警异常增长趋势。

4. 流程图：VMDK空间回收全过程

graph TD
            A[Guest OS 删除文件] --> B{是否启用TRIM/discard?}
            B -- 是 --> C[OS 发送UNMAP/Trim命令]
            B -- 否 --> D[运行sdelete/fstrim填充零块]
            D --> E[VMkernel检测零块]
            C --> E
            E --> F{磁盘类型为Thin?}
            F -- 是 --> G[ESXi释放物理存储空间]
            F -- 否 --> H[空间无法回收]
            G --> I[Datastore空间下降]
            H --> J[VMDK持续膨胀]

5. 高阶注意事项与最佳实践

• UNMAP在跨vCenter迁移或跨集群复制时可能失效，需验证目标端兼容性；
• 某些All-Flash阵列对UNMAP响应较慢，应结合阵列侧GC机制协同优化；
• 快照存在时，空间回收受限，因旧数据仍需保留；
• 建议在维护窗口执行大规模空间回收，避免I/O性能波动；
• 监控esxtop中的UNMAP速率，评估回收效率；
• 考虑采用VMware vSAN环境下的自动空间回收策略；
• 对于数据库类工作负载，推荐定期导出重建以控制碎片；
• 使用第三方工具如RVTools分析VMDK实际利用率；
• 启用Storage IO Control提升高密度场景下的公平性；
• 建立容量规划模型，预测VMDK增长趋势。