拓冰网站定制 
简介这份文档面向 VMware 虚拟化运维人员与存储管理员聚焦 ESXi 环境下精简磁盘Thin空间无法自动释放的常见痛点给出可落地的回收思路与操作参考。资源包内仅含 1 个 docx 文件约 408KB以图文步骤形式记录两种回收方案一是借助 SDelete 清理 Windows 空闲空间后通过 SSH 登录 ESXi 主机执行 vmkfstools 回收 vmdk 空间二是利用 Storage VMotion 在线迁移将磁盘格式切换为厚置备延迟归零再迁回 Thin实现空间释放。内容结合 Server2012R2 实测场景展示磁盘实际占用与 VMDK 占用不一致的排查过程并说明停机与在线两种方式的适用条件。目前已有 2000 余人学习适合需要处理精简卷空间浪费、优化存储利用率的运维人员参考。1. 精简磁盘空间回收为什么删了文件虚拟机还是喊饿在 VMware Workstation 里跑 Windows 或 Linux 虚拟机的人几乎都遇到过这个场景客户机里明明删掉了几十 GB 的日志、缓存、旧镜像df -h或资源管理器看着是空出来了可宿主机上那个.vmdk文件纹丝不动硬盘照样被吃掉。这不是玄学而是虚拟磁盘的工作方式决定的——客户机操作系统只知道自己有一块「物理盘」它把块标记为空闲但 VMware 看到的仍是当初分配出去的那片扇区。所谓精简磁盘空间回收就是让客户机把「哪些块已经没用了」这件事告诉 VMware再由 VMware 把这些块在宿主机文件里真正释放掉。它解决的是虚拟磁盘只涨不缩的顽疾适合长期跑测试环境、做快照堆积、或者把虚拟机当开发机天天写日志的人。搞懂这条链路你的宿主机才能把空间还回来。2. 先分清三种磁盘格式回收能不能做开局就定了2.1 厚置备、精简置备与预分配的区别VMware Workstation 创建虚拟磁盘时常见的有这么几类预分配厚置备会一次性把整块磁盘大小写到宿主机文件里比如你给 100 GB宿主机立刻少 100 GB精简置备thin则按需增长用多少涨多少。回收这件事本质上只对精简置备有意义——厚置备的块从一开始就全占着客户机删文件不会让宿主机文件变小除非你做磁盘压缩把它转成精简。判断当前磁盘属于哪种最直接的办法是看.vmdk文件的实际大小和虚拟机设置里标称容量的差距。如果标称 100 GB、实际文件只有 30 GB那基本就是精简置备回收有戏如果实际文件就是 100 GB 左右那要么是预分配要么是精简盘已经涨满了。提示回收操作前先关机或至少确保没有正在写入的快照带快照的磁盘回收经常只回收了个寂寞。2.2 回收链路客户机标记、VMware Tools 传递、宿主机落盘完整的回收链路分三段。第一段在客户机内部操作系统把删除的块标记为空闲但这一步只是逻辑标记第二段靠 VMware Tools 里的驱动或后台服务把这些空闲块信息收集起来第三段由 VMware 在宿主机侧执行压缩把空闲块对应的宿主机文件区域真正释放。任何一段断了回收都会失败。这也是为什么很多人装了 VMware Tools 却还是回收不了——Tools 装了不等于相关服务在跑也不等于客户机文件系统支持这种「空洞传递」。NTFS、ext4 这类主流文件系统支持得比较好一些老旧的 FAT 或者加密卷就经常掉链子。2.3 用命令行确认磁盘当前状态在动手之前先在宿主机上把虚拟机的磁盘信息摸清楚。Windows 宿主机可以用vmware-vdiskmanagerLinux 宿主机同样有这个工具路径一般在 VMware 安装目录下。# 查看虚拟磁盘详细信息确认类型和当前占用 vmware-vdiskmanager -i D:\VMs\Win11Dev\Win11Dev.vmdk # 输出里重点关注 type 字段 # growable 表示精简置备可以回收 # preallocated 表示厚置备需要先转换-i是查询信息不会改动任何东西放心跑。输出里的type决定了你后面走哪条路growable直接进回收流程preallocated得先用-r转成精简再谈回收。这一步别省我见过太多人上来就压缩结果对着一个厚置备盘折腾半天宿主机空间一点没变。3. 客户机侧准备让空闲块真正「空」出来3.1 Windows 客户机的清理与碎片整理顺序Windows 客户机回收失败十有八九是顺序搞反了。正确顺序是先清理无用文件再做碎片整理最后才触发回收。碎片整理会把分散的空闲块聚拢让后续的回收更彻底如果先回收再整理整理过程又会产生新的碎片等于白干。清理时重点盯这几类C:\Windows\Temp、用户目录下的AppData\Local\Temp、各种包管理器的缓存npm、pip、NuGet、旧的系统还原点和 Windows 更新缓存。Windows 更新缓存尤其能吃空间用系统自带的磁盘清理勾上「Windows 更新清理」往往能腾出好几个 GB。# 以管理员身份运行清理更新缓存和临时文件 Dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase # 清理系统临时目录 Remove-Item -Path $env:TEMP\* -Recurse -Force -ErrorAction SilentlyContinue Remove-Item -Path C:\Windows\Temp\* -Recurse -Force -ErrorAction SilentlyContinue/StartComponentCleanup清理被取代的组件版本/ResetBase会重置更新基线代价是之后无法卸载已安装的更新——测试机可以这么干生产机要谨慎。清理完记得重启一次让系统把删除操作彻底落盘再进行碎片整理。3.2 Linux 客户机的 TRIM 与零填充Linux 这边思路类似但工具不同。ext4 支持fstrim前提是虚拟磁盘控制器支持 discard 传递。VMware 的虚拟 SCSI 控制器在较新版本里支持这个特性但需要客户机内核和 Tools 配合。# 先看文件系统是否支持 discard sudo fstrim -v / # 如果报 the discard operation is not supported # 说明控制器或文件系统没开这个能力改用零填充方案 sudo dd if/dev/zero of/zero.fill bs1M statusprogress sudo rm -f /zero.fill sudo syncfstrim -v /会告诉文件系统把空闲块标记出来-v输出回收了多少字节。如果这条路走不通就用dd写一个占满剩余空间的大文件再删掉——这个操作会把所有空闲块用零覆盖一遍VMware 后续压缩时就能识别出这些全零块并释放。bs1M是块大小statusprogress让你看到进度别用太小的块否则慢得让人想砸键盘。注意零填充会临时占满磁盘确保宿主机有足够空间承接这个峰值别在宿主机快满的时候干这事。3.3 确认 VMware Tools 相关服务在跑回收依赖 Tools 的后台能力光装了不够得确认服务活着。Windows 客户机看服务列表里的VMware Tools Service和VMware 磁盘挂载相关项Linux 客户机用systemctl status vmtoolsd查。# Linux 客户机检查 Tools 服务状态 systemctl status vmtoolsd # 如果没跑启动并设为开机自启 sudo systemctl enable --now vmtoolsd服务没起来客户机标记的空闲块信息就传不出去宿主机侧自然无从回收。这一步是很多「我明明清理了却没用」的根因排查时优先看。4. 宿主机侧执行压缩命令与参数怎么调4.1 关机后用 vdiskmanager 压缩最稳妥的回收方式是在虚拟机关机状态下用vmware-vdiskmanager做压缩。关机是为了避免写入干扰压缩过程中如果有新数据落盘结果会不一致。# 关机后执行压缩-k 表示收缩磁盘 vmware-vdiskmanager -k D:\VMs\Win11Dev\Win11Dev.vmdk # 如果磁盘是厚置备先转精简再压缩 vmware-vdiskmanager -r D:\VMs\Win11Dev\Win11Dev.vmdk -t 0 D:\VMs\Win11Dev\Win11Dev-thin.vmdk vmware-vdiskmanager -k D:\VMs\Win11Dev\Win11Dev-thin.vmdk-k是收缩它会扫描磁盘里的空闲块并释放。-r是转换-t 0指定目标类型为精简置备0 代表 growable。转换会生成一个新文件原文件保留确认新盘能用之后再删旧的。转换过程可能很久100 GB 的盘在机械硬盘上跑一两个小时很正常别以为卡死了。4.2 图形界面里的磁盘压缩入口不想敲命令的话VMware Workstation 的图形界面也提供了压缩入口。选中虚拟机进「虚拟机设置」→「硬盘」→「磁盘实用工具」→「压缩」。这个入口底层调的还是同一套逻辑适合偶尔用一次的人。但要注意图形界面的压缩按钮在某些版本里对厚置备盘是灰的这时候还是得回到命令行转换。4.3 压缩前后对比与验证压缩完别急着高兴先验证。对比压缩前后.vmdk文件的大小再看虚拟机能不能正常启动、数据有没有丢。# 压缩前后各跑一次对比文件大小 ls -lh D:\VMs\Win11Dev\Win11Dev.vmdk # 启动虚拟机后在客户机里确认文件系统正常 # Linux: df -h # Windows: 资源管理器看各分区容量如果压缩后文件没怎么变小常见原因是客户机里空闲块没被正确标记回到第 3 章检查或者磁盘本身就没多少可回收空间。如果压缩后虚拟机起不来多半是压缩过程中文件损坏这时候快照或备份就是你的后悔药——所以压缩前做一次完整备份这个习惯能救命。5. 避坑与排查回收失败的五个典型现场5.1 压缩后宿主机空间没变化现象命令跑完提示成功但宿主机可用空间几乎没动。原因通常是磁盘本身是厚置备或者客户机空闲块没标记。解决先用-i确认磁盘类型厚置备先转精简再回客户机确认清理和零填充做到位Tools 服务在跑。5.2 带快照的虚拟机压缩报错现象压缩时提示磁盘有快照或无法锁定。原因快照文件依赖基础磁盘压缩会破坏快照链。解决先在快照管理器里删除或合并快照再关机压缩。如果快照很重要先克隆一份出来单独处理。5.3 Linux 客户机 fstrim 报不支持现象fstrim -v /返回不支持的操作。原因虚拟 SCSI 控制器没开 discard 传递或文件系统挂载时没启用相关选项。解决改用dd零填充方案或者检查虚拟机设置里 SCSI 控制器类型换成支持 discard 的型号后重启再试。5.4 压缩过程卡住或极慢现象压缩进度长时间不动。原因宿主机磁盘本身碎片严重或虚拟磁盘文件过大。解决先给宿主机做一次碎片整理确保宿主机有足够连续空间大磁盘分批处理别指望一次搞定。机械硬盘上慢是正常的换 SSD 会快很多。5.5 压缩后客户机文件系统报错现象虚拟机启动后提示文件系统损坏或需要检查。原因压缩过程中断电、宿主机空间不足导致写入中断。解决用客户机自带的文件系统检查工具修复Windows 的chkdsk、Linux 的fsck修复不了就从备份恢复。这也是为什么压缩前备份不能省。6. 把回收做成习惯自动化脚本与长期维护回收不是一锤子买卖虚拟机用久了空间又会涨回去。与其每次手动折腾不如把它做成定期维护。我的做法是给每台长期使用的虚拟机写一个维护脚本客户机侧负责清理和零填充宿主机侧负责压缩两边配合。#!/bin/bash # 客户机侧维护脚本放在 Linux 客户机里定期跑 set -e echo 清理包管理器缓存... sudo apt-get clean sudo apt-get autoremove -y echo 清理日志... sudo journalctl --vacuum-time7d echo 零填充空闲块... sudo dd if/dev/zero of/zero.fill bs1M statusprogress || true sudo rm -f /zero.fill sudo sync echo 客户机侧完成请在宿主机执行压缩这个脚本的逻辑是先清缓存和旧日志再用零填充把空闲块覆盖最后同步落盘。journalctl --vacuum-time7d只保留最近七天的日志按需调整天数。|| true是为了让dd写满磁盘报错时不中断脚本——写满本来就是预期行为。宿主机侧对应一个压缩脚本关机后调用#!/bin/bash # 宿主机侧压缩脚本Linux 宿主机示例 VMDK/path/to/your/vm/disk.vmdk echo 压缩前大小 ls -lh $VMDK vmware-vdiskmanager -k $VMDK echo 压缩后大小 ls -lh $VMDK两个脚本配合每月跑一次虚拟机的空间占用就能控制在一个合理范围。Windows 客户机的话把清理部分换成 PowerShell 的清理命令零填充用cipher /w:C或者写零文件的方式思路完全一样。一个我踩过的坑早期我图省事在虚拟机运行状态下直接压缩结果压缩到一半客户机还在写日志压缩完文件大小没变多少还差点把文件系统搞坏。从那以后我给自己定了死规矩——压缩前必须关机必须备份必须确认 Tools 服务正常。这三条看着啰嗦但省下的返工时间远超这点准备成本。回收这件事慢就是快稳就是省。希望帮到你。本文还有配套的精品资源点击获取 VMware虚拟机精简磁盘空间回收：原理、命令与避坑指南
简介这份文档面向 VMware 虚拟化运维人员与存储管理员聚焦 ESXi 环境下精简磁盘Thin空间无法自动释放的常见痛点给出可落地的回收思路与操作参考。资源包内仅含 1 个 docx 文件约 408KB以图文步骤形式记录两种回收方案一是借助 SDelete 清理 Windows 空闲空间后通过 SSH 登录 ESXi 主机执行 vmkfstools 回收 vmdk 空间二是利用 Storage VMotion 在线迁移将磁盘格式切换为厚置备延迟归零再迁回 Thin实现空间释放。内容结合 Server2012R2 实测场景展示磁盘实际占用与 VMDK 占用不一致的排查过程并说明停机与在线两种方式的适用条件。目前已有 2000 余人学习适合需要处理精简卷空间浪费、优化存储利用率的运维人员参考。1. 精简磁盘空间回收为什么删了文件虚拟机还是喊饿在 VMware Workstation 里跑 Windows 或 Linux 虚拟机的人几乎都遇到过这个场景客户机里明明删掉了几十 GB 的日志、缓存、旧镜像df -h或资源管理器看着是空出来了可宿主机上那个.vmdk文件纹丝不动硬盘照样被吃掉。这不是玄学而是虚拟磁盘的工作方式决定的——客户机操作系统只知道自己有一块「物理盘」它把块标记为空闲但 VMware 看到的仍是当初分配出去的那片扇区。所谓精简磁盘空间回收就是让客户机把「哪些块已经没用了」这件事告诉 VMware再由 VMware 把这些块在宿主机文件里真正释放掉。它解决的是虚拟磁盘只涨不缩的顽疾适合长期跑测试环境、做快照堆积、或者把虚拟机当开发机天天写日志的人。搞懂这条链路你的宿主机才能把空间还回来。2. 先分清三种磁盘格式回收能不能做开局就定了2.1 厚置备、精简置备与预分配的区别VMware Workstation 创建虚拟磁盘时常见的有这么几类预分配厚置备会一次性把整块磁盘大小写到宿主机文件里比如你给 100 GB宿主机立刻少 100 GB精简置备thin则按需增长用多少涨多少。回收这件事本质上只对精简置备有意义——厚置备的块从一开始就全占着客户机删文件不会让宿主机文件变小除非你做磁盘压缩把它转成精简。判断当前磁盘属于哪种最直接的办法是看.vmdk文件的实际大小和虚拟机设置里标称容量的差距。如果标称 100 GB、实际文件只有 30 GB那基本就是精简置备回收有戏如果实际文件就是 100 GB 左右那要么是预分配要么是精简盘已经涨满了。提示回收操作前先关机或至少确保没有正在写入的快照带快照的磁盘回收经常只回收了个寂寞。2.2 回收链路客户机标记、VMware Tools 传递、宿主机落盘完整的回收链路分三段。第一段在客户机内部操作系统把删除的块标记为空闲但这一步只是逻辑标记第二段靠 VMware Tools 里的驱动或后台服务把这些空闲块信息收集起来第三段由 VMware 在宿主机侧执行压缩把空闲块对应的宿主机文件区域真正释放。任何一段断了回收都会失败。这也是为什么很多人装了 VMware Tools 却还是回收不了——Tools 装了不等于相关服务在跑也不等于客户机文件系统支持这种「空洞传递」。NTFS、ext4 这类主流文件系统支持得比较好一些老旧的 FAT 或者加密卷就经常掉链子。2.3 用命令行确认磁盘当前状态在动手之前先在宿主机上把虚拟机的磁盘信息摸清楚。Windows 宿主机可以用vmware-vdiskmanagerLinux 宿主机同样有这个工具路径一般在 VMware 安装目录下。# 查看虚拟磁盘详细信息确认类型和当前占用 vmware-vdiskmanager -i D:\VMs\Win11Dev\Win11Dev.vmdk # 输出里重点关注 type 字段 # growable 表示精简置备可以回收 # preallocated 表示厚置备需要先转换-i是查询信息不会改动任何东西放心跑。输出里的type决定了你后面走哪条路growable直接进回收流程preallocated得先用-r转成精简再谈回收。这一步别省我见过太多人上来就压缩结果对着一个厚置备盘折腾半天宿主机空间一点没变。3. 客户机侧准备让空闲块真正「空」出来3.1 Windows 客户机的清理与碎片整理顺序Windows 客户机回收失败十有八九是顺序搞反了。正确顺序是先清理无用文件再做碎片整理最后才触发回收。碎片整理会把分散的空闲块聚拢让后续的回收更彻底如果先回收再整理整理过程又会产生新的碎片等于白干。清理时重点盯这几类C:\Windows\Temp、用户目录下的AppData\Local\Temp、各种包管理器的缓存npm、pip、NuGet、旧的系统还原点和 Windows 更新缓存。Windows 更新缓存尤其能吃空间用系统自带的磁盘清理勾上「Windows 更新清理」往往能腾出好几个 GB。# 以管理员身份运行清理更新缓存和临时文件 Dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase # 清理系统临时目录 Remove-Item -Path $env:TEMP\* -Recurse -Force -ErrorAction SilentlyContinue Remove-Item -Path C:\Windows\Temp\* -Recurse -Force -ErrorAction SilentlyContinue/StartComponentCleanup清理被取代的组件版本/ResetBase会重置更新基线代价是之后无法卸载已安装的更新——测试机可以这么干生产机要谨慎。清理完记得重启一次让系统把删除操作彻底落盘再进行碎片整理。3.2 Linux 客户机的 TRIM 与零填充Linux 这边思路类似但工具不同。ext4 支持fstrim前提是虚拟磁盘控制器支持 discard 传递。VMware 的虚拟 SCSI 控制器在较新版本里支持这个特性但需要客户机内核和 Tools 配合。# 先看文件系统是否支持 discard sudo fstrim -v / # 如果报 the discard operation is not supported # 说明控制器或文件系统没开这个能力改用零填充方案 sudo dd if/dev/zero of/zero.fill bs1M statusprogress sudo rm -f /zero.fill sudo syncfstrim -v /会告诉文件系统把空闲块标记出来-v输出回收了多少字节。如果这条路走不通就用dd写一个占满剩余空间的大文件再删掉——这个操作会把所有空闲块用零覆盖一遍VMware 后续压缩时就能识别出这些全零块并释放。bs1M是块大小statusprogress让你看到进度别用太小的块否则慢得让人想砸键盘。注意零填充会临时占满磁盘确保宿主机有足够空间承接这个峰值别在宿主机快满的时候干这事。3.3 确认 VMware Tools 相关服务在跑回收依赖 Tools 的后台能力光装了不够得确认服务活着。Windows 客户机看服务列表里的VMware Tools Service和VMware 磁盘挂载相关项Linux 客户机用systemctl status vmtoolsd查。# Linux 客户机检查 Tools 服务状态 systemctl status vmtoolsd # 如果没跑启动并设为开机自启 sudo systemctl enable --now vmtoolsd服务没起来客户机标记的空闲块信息就传不出去宿主机侧自然无从回收。这一步是很多「我明明清理了却没用」的根因排查时优先看。4. 宿主机侧执行压缩命令与参数怎么调4.1 关机后用 vdiskmanager 压缩最稳妥的回收方式是在虚拟机关机状态下用vmware-vdiskmanager做压缩。关机是为了避免写入干扰压缩过程中如果有新数据落盘结果会不一致。# 关机后执行压缩-k 表示收缩磁盘 vmware-vdiskmanager -k D:\VMs\Win11Dev\Win11Dev.vmdk # 如果磁盘是厚置备先转精简再压缩 vmware-vdiskmanager -r D:\VMs\Win11Dev\Win11Dev.vmdk -t 0 D:\VMs\Win11Dev\Win11Dev-thin.vmdk vmware-vdiskmanager -k D:\VMs\Win11Dev\Win11Dev-thin.vmdk-k是收缩它会扫描磁盘里的空闲块并释放。-r是转换-t 0指定目标类型为精简置备0 代表 growable。转换会生成一个新文件原文件保留确认新盘能用之后再删旧的。转换过程可能很久100 GB 的盘在机械硬盘上跑一两个小时很正常别以为卡死了。4.2 图形界面里的磁盘压缩入口不想敲命令的话VMware Workstation 的图形界面也提供了压缩入口。选中虚拟机进「虚拟机设置」→「硬盘」→「磁盘实用工具」→「压缩」。这个入口底层调的还是同一套逻辑适合偶尔用一次的人。但要注意图形界面的压缩按钮在某些版本里对厚置备盘是灰的这时候还是得回到命令行转换。4.3 压缩前后对比与验证压缩完别急着高兴先验证。对比压缩前后.vmdk文件的大小再看虚拟机能不能正常启动、数据有没有丢。# 压缩前后各跑一次对比文件大小 ls -lh D:\VMs\Win11Dev\Win11Dev.vmdk # 启动虚拟机后在客户机里确认文件系统正常 # Linux: df -h # Windows: 资源管理器看各分区容量如果压缩后文件没怎么变小常见原因是客户机里空闲块没被正确标记回到第 3 章检查或者磁盘本身就没多少可回收空间。如果压缩后虚拟机起不来多半是压缩过程中文件损坏这时候快照或备份就是你的后悔药——所以压缩前做一次完整备份这个习惯能救命。5. 避坑与排查回收失败的五个典型现场5.1 压缩后宿主机空间没变化现象命令跑完提示成功但宿主机可用空间几乎没动。原因通常是磁盘本身是厚置备或者客户机空闲块没标记。解决先用-i确认磁盘类型厚置备先转精简再回客户机确认清理和零填充做到位Tools 服务在跑。5.2 带快照的虚拟机压缩报错现象压缩时提示磁盘有快照或无法锁定。原因快照文件依赖基础磁盘压缩会破坏快照链。解决先在快照管理器里删除或合并快照再关机压缩。如果快照很重要先克隆一份出来单独处理。5.3 Linux 客户机 fstrim 报不支持现象fstrim -v /返回不支持的操作。原因虚拟 SCSI 控制器没开 discard 传递或文件系统挂载时没启用相关选项。解决改用dd零填充方案或者检查虚拟机设置里 SCSI 控制器类型换成支持 discard 的型号后重启再试。5.4 压缩过程卡住或极慢现象压缩进度长时间不动。原因宿主机磁盘本身碎片严重或虚拟磁盘文件过大。解决先给宿主机做一次碎片整理确保宿主机有足够连续空间大磁盘分批处理别指望一次搞定。机械硬盘上慢是正常的换 SSD 会快很多。5.5 压缩后客户机文件系统报错现象虚拟机启动后提示文件系统损坏或需要检查。原因压缩过程中断电、宿主机空间不足导致写入中断。解决用客户机自带的文件系统检查工具修复Windows 的chkdsk、Linux 的fsck修复不了就从备份恢复。这也是为什么压缩前备份不能省。6. 把回收做成习惯自动化脚本与长期维护回收不是一锤子买卖虚拟机用久了空间又会涨回去。与其每次手动折腾不如把它做成定期维护。我的做法是给每台长期使用的虚拟机写一个维护脚本客户机侧负责清理和零填充宿主机侧负责压缩两边配合。#!/bin/bash # 客户机侧维护脚本放在 Linux 客户机里定期跑 set -e echo 清理包管理器缓存... sudo apt-get clean sudo apt-get autoremove -y echo 清理日志... sudo journalctl --vacuum-time7d echo 零填充空闲块... sudo dd if/dev/zero of/zero.fill bs1M statusprogress || true sudo rm -f /zero.fill sudo sync echo 客户机侧完成请在宿主机执行压缩这个脚本的逻辑是先清缓存和旧日志再用零填充把空闲块覆盖最后同步落盘。journalctl --vacuum-time7d只保留最近七天的日志按需调整天数。|| true是为了让dd写满磁盘报错时不中断脚本——写满本来就是预期行为。宿主机侧对应一个压缩脚本关机后调用#!/bin/bash # 宿主机侧压缩脚本Linux 宿主机示例 VMDK/path/to/your/vm/disk.vmdk echo 压缩前大小 ls -lh $VMDK vmware-vdiskmanager -k $VMDK echo 压缩后大小 ls -lh $VMDK两个脚本配合每月跑一次虚拟机的空间占用就能控制在一个合理范围。Windows 客户机的话把清理部分换成 PowerShell 的清理命令零填充用cipher /w:C或者写零文件的方式思路完全一样。一个我踩过的坑早期我图省事在虚拟机运行状态下直接压缩结果压缩到一半客户机还在写日志压缩完文件大小没变多少还差点把文件系统搞坏。从那以后我给自己定了死规矩——压缩前必须关机必须备份必须确认 Tools 服务正常。这三条看着啰嗦但省下的返工时间远超这点准备成本。回收这件事慢就是快稳就是省。希望帮到你。本文还有配套的精品资源点击获取