别再浪费存储了！手把手教你用vmkfstools回收ESXi虚拟机瘦磁盘空间
ESXi虚拟机存储优化实战：彻底回收瘦磁盘空间
虚拟化环境中，存储空间的管理一直是管理员们头疼的问题。特别是使用ESXi虚拟化平台时，即使选择了精简置备（Thin Provisioning）模式，虚拟机磁盘文件（VMDK）也会像气球一样只胀不缩。想象一下这样的场景：你的虚拟机曾经需要800GB空间，现在删除了600GB文件，但VMDK文件依然顽固地占据着800GB物理存储。这不仅浪费宝贵的存储资源，还会显著影响虚拟机迁移和备份的效率。
1. 理解ESXi虚拟磁盘的工作原理
在深入解决方案之前，我们需要先搞清楚为什么精简置备的磁盘会表现出这种"只增不减"的特性。
1.1 三种虚拟磁盘类型对比
| 磁盘类型 | 空间分配时机 | 置零时机 | 性能影响 | 空间利用率 |
|---|---|---|---|---|
| 厚置备延迟置零 | 创建时全部分配 | 写入时置零 | 中等 | 低 |
| 厚置备立即置零 | 创建时全部分配 | 创建时置零 | 高（创建耗时） | 低 |
| 精简置备 | 按需动态分配 | 写入时置零 | 中等（分配时延迟） | 高 |
精简置备虽然提高了存储利用率，但其设计机制决定了它不会自动回收已释放的空间。当虚拟机删除文件时，ESXi并不会主动将这些空间标记为可用，这就是为什么我们需要手动干预来回收这些"幽灵"空间。
1.2 为什么精简磁盘不会自动缩小
精简置备磁盘的"膨胀"行为源于几个关键技术原因：
- 文件系统层与虚拟化层的分离：虚拟机内部的文件系统操作（如删除文件）不会直接传递到底层的VMDK文件
- 性能优化考虑：频繁的空间回收操作会影响I/O性能
- 数据安全机制：保留已分配空间可以防止数据碎片化和潜在的安全问题
关键点：即使你在虚拟机内部格式化整个磁盘，VMDK文件大小依然保持不变，因为这些操作只影响虚拟磁盘内部的元数据，而非物理存储分配。
2. 空间回收前的准备工作
在开始回收空间之前，有几个必要的准备步骤不容忽视。
2.1 启用ESXi的SSH服务
由于空间回收操作需要通过命令行完成，我们需要先确保能访问ESXi的SSH服务：
- 在vSphere Client中导航到"主机" → "管理" → "服务"
- 找到"TSM-SSH"服务并右键启动
- （可选）设置服务随主机自动启动：
- 右键"TSM-SSH" → "策略" → "随主机启动和停止"
注意：出于安全考虑，建议在完成所有操作后关闭SSH服务，特别是在生产环境中。
2.2 检查并清理虚拟机快照
快照会严重影响磁盘操作的安全性，必须确保：
- 关闭目标虚拟机电源
- 删除所有现有快照
- 确认虚拟机使用的是精简置备磁盘：
在输出中查找"thin"确认磁盘类型vmkfstools -D /vmfs/volumes/datastore1/VM_NAME/VM_NAME.vmdk
常见问题：如果虚拟机有未合并的快照，空间回收操作可能会失败或导致数据不一致。
3. 空间置零：回收前的关键步骤
真正的空间回收过程分为两个阶段：首先在虚拟机内部将空闲空间置零，然后在ESXi层面回收这些零块。
3.1 虚拟机内部的置零操作
登录到目标虚拟机，执行以下操作：
确认可用空间大小：
df -h使用dd命令填充空闲空间：
dd if=/dev/zero of=/zero.file bs=1M; sync; rm /zero.file对于不同操作系统，可能需要调整命令：
- Windows系统：使用
sdelete工具：sdelete -z C: - Linux系统：也可以使用更高效的方法：
cat /dev/zero > /zero.file; sync; rm /zero.file
- Windows系统：使用
对于有多个分区的系统，需要为每个分区重复此操作
重要提示：确保磁盘有足够的空闲空间来创建临时零文件，否则可能导致系统崩溃。
3.2 置零操作的原理与注意事项
置零过程实际上是在告诉虚拟化层："这些空间现在包含已知数据（全零），可以被安全回收"。这与传统文件删除有本质区别：
- 普通删除：只移除文件系统索引，数据仍存在于物理块中
- 置零操作：显式地用零填充数据块，使虚拟化层能识别可回收空间
性能考虑：置零操作会产生大量I/O，建议在非业务高峰期进行，并确保虚拟机有足够的内存和CPU资源。
4. 使用vmkfstools回收磁盘空间
完成虚拟机内部的置零后，就可以在ESXi主机上执行实际的回收操作了。
4.1 基本回收命令
通过SSH登录ESXi主机
导航到虚拟机目录：
cd /vmfs/volumes/datastore1/VM_NAME执行空间回收：
vmkfstools -K VM_NAME.vmdk这个过程可能需要较长时间，取决于磁盘大小和已使用空间比例
验证回收结果：
du -h *
4.2 常见错误与解决方案
错误1：Could not punch hole in disk: Function not implemented
- 原因：磁盘不是精简置备格式
- 解决方案：先将磁盘转换为精简置备：
vmkfstools -i original.vmdk -d thin thin.vmdk
错误2：Failed to lock the file
- 原因：虚拟机未完全关闭或有残留进程
- 解决方案：确认虚拟机完全关闭，必要时重启ESXi主机
错误3：空间回收后大小没有变化
- 原因1：置零操作未正确执行
- 解决方案：重新检查虚拟机内部的置零过程
- 原因2：磁盘碎片化严重
- 解决方案：考虑使用
vmkfstools --defragment先整理磁盘
4.3 高级技巧：批量回收多个虚拟机
对于需要回收多个虚拟机空间的环境，可以编写简单的shell脚本：
#!/bin/sh for vm in $(ls /vmfs/volumes/datastore1); do echo "Processing $vm..." vmkfstools -K "/vmfs/volumes/datastore1/$vm/$vm.vmdk" done5. 最佳实践与长期管理策略
一次性回收空间只是解决方案的一部分，建立长期有效的管理机制更为重要。
5.1 自动化空间回收方案
定期回收计划：
- 创建每月执行的自动化任务
- 结合vSphere API实现无干预回收
存储监控与警报：
- 设置VMDK增长阈值警报
- 监控存储阵列的物理空间使用率
虚拟机模板优化：
# 创建已优化的模板 vmkfstools -i source.vmdk -d thin template.vmdk --punchzero
5.2 不同场景下的策略选择
| 场景 | 推荐策略 | 注意事项 |
|---|---|---|
| 开发/测试环境 | 每月回收 | 影响较小，可频繁操作 |
| 生产数据库 | 季度回收+维护窗口 | 需要严格测试和备份 |
| VDI环境 | 注销时回收 | 结合用户注销流程 |
| 备份服务器 | 备份后回收 | 确保备份完整性 |
5.3 性能与安全的平衡点
虽然空间回收能节省存储，但也需要考虑以下因素：
- I/O影响：回收操作期间避免运行敏感应用
- SSD磨损：对全闪存存储不宜过于频繁回收
- 备份策略：回收前后建议执行完整备份
在多个实际案例中，合理应用这些技术可以帮助企业节省30-60%的存储空间，同时提高备份和迁移效率。例如，一个原本需要8小时完成的虚拟机迁移，在回收空间后可能只需2-3小时。