虚拟机磁盘缩小后空间未释放，核心原因是客户机内的删除操作不会自动同步到宿主机上的虚拟磁盘文件，需要手动执行清零和压缩两步操作才能找回空间。
为什么虚拟机磁盘缩小后宿主机空间没有变化
多数情况下，虚拟磁盘采用动态分配模式，比如VMware的thin provisioning、QEMU的qcow2格式，这类磁盘文件的大小会随着虚拟机内部数据的写入而增长，但删除数据时却不会自动缩小，这是设计使然,原因在于虚拟磁盘文件与物理磁盘的映射机制。
客户机删除文件不等于磁盘数据清除
虚拟机内部删除文件时，操作系统只是把文件系统里对应的元数据标记为可用，底层数据块仍然保留原内容，对于宿主机来说，这些数据块依然被虚拟磁盘文件占据，行业共识认为，客户机内的删除操作在底层只是“标记覆盖”，而非物理清除。
稀疏文件特性导致空间“看起来还在”
动态虚拟磁盘在宿主机上本质是一个稀疏文件，当你往虚拟机里写入数据时，宿主机上的文件逐步变大；当你删除虚拟机内数据时，宿主机上的文件不会自动瘦身，只有对虚拟磁盘执行专门的操作，把那些“已删除但仍有内容”的数据块清零，宿主机才能识别这些块为空洞,从而在文件系统层面释放占用。
快照和日志文件干扰空间释放
如果你的虚拟机启用了快照或者有大量磁盘日志，删除数据后的空间释放会更加延迟，快照会保留原数据块的副本，任何对磁盘的写入都会让快照文件继续增长，这种情况下，即使你在客户机里删除大量文件,宿主机上的磁盘占用反而可能变大。
虚拟机磁盘删了文件空间没变小？先确认空间确实“被吃掉”了
在执行任何压缩操作之前，先确认两侧的真实状态，很多用户以为空间没释放，实际是因为宿主机上还有其他占用,或者虚拟磁盘本身已经被撑大到了某个阈值。
客户机内确认文件系统层空间
在Windows虚拟机中，打开“此电脑”→右键系统盘→属性，查看可用空间，在Linux虚拟机中，执行df -h确认分区使用率，这一步能确认客户机内部是否真的腾出了空间，如果客户机内部空间依然紧张，说明删除动作本身没成功,或文件被占用无法删除。
宿主机侧确认虚拟磁盘文件大小
进入虚拟机存储目录，查看vmdk、qcow2或vhd/vhdx文件的实际大小，以VMware Workstation为例，默认存储在C:Users用户名DocumentsVirtual Machines下；KVM虚拟机镜像通常在/var/lib/libvirt/images/下。
对比客户机可用空间和宿主机磁盘文件大小：客户机显示剩余50GB，vmdk文件却仍然占80GB,这就是需要回收的空间。
确认没有快照干扰
在VMware Workstation中点击“虚拟机”→“快照”→“快照管理器”，查看是否存在快照，在KVM环境中执行virsh snapshot-list <虚拟机名>，如果有快照，需要先删除或合并，否则后续压缩操作可能失败,或压缩后空间释放不明显。
如何找回未释放的虚拟磁盘空间
核心思路分三步：整理客户机内部空闲空间→把空闲区域清零→宿主机上执行压缩/转换命令。
第一步：客户机内用工具清零空闲空间
这一步的目的，是把客户机里“已删除但仍有内容”的数据块用零覆盖，让宿主机识别这些块为“空”。
Windows客户机操作：
- 以管理员身份打开命令提示符。
- 下载微软官方的Sysinternals工具包,解压后进入目录。
- 执行
sdelete -z C:（C:替换为实际盘符）,等待清零完成。
Linux客户机操作：
- 如果根分区是ext3/ext4，执行
zerofree -v /dev/sda1（先通过mount命令确认设备名，必要时以只读方式挂载）。 - 如果根分区是xfs，执行
fstrim -v /（在支持discard的环境下有效）。 - 如果不确定文件系统类型，直接执行
cat /dev/zero > /tmp/zero.bin; rm -f /tmp/zero.bin，这会在磁盘上写满零再删除,效果类似。
第二步：在宿主机执行压缩操作
清零完成后，关闭虚拟机,回到宿主机执行压缩命令。
VMware Workstation / ESXi：
- Windows宿主机（VMware Workstation）：
- 找到vmware-vdiskmanager.exe，通常位于
C:Program Files (x86)VMwareVMware Workstation。 -
执行
vmware-vdiskmanager.exe -k "虚拟机磁盘完整路径.vmdk"。
- 找到vmware-vdiskmanager.exe，通常位于
- ESXi宿主机：
- 启用SSH，登录后执行
vmkfstools -K <磁盘完整路径>，或者通过vSphere Client的“存储”→“精简置备”直接压缩。
- 启用SSH，登录后执行
KVM / QEMU：
- 使用qemu-img转换命令，执行
qemu-img convert -p -O qcow2 原镜像.qcow2 新镜像.qcow2。 - 更推荐用virt-sparsify工具：
virt-sparsify --in-place 原镜像.qcow2，该工具会自动检测并释放稀疏空间，速度和效果都优于qemu-img。 - 注意：转换前确保有足够的临时存储空间,转换完成后用新镜像替换旧镜像。
Hyper-V：
- 在PowerShell中执行
Optimize-VHD -Path <磁盘路径> -Mode Full。 - 也可以在Hyper-V管理器中右键虚拟硬盘→“压缩”完成操作。
第三步：验证空间回收结果
压缩完成后，回到宿主机查看虚拟磁盘文件大小，以VMware Workstation为例，压缩前后vmdk大小明显缩小，说明空间已成功释放，如果压缩后大小没有变化，大概率是客户机清零步骤没做完整,或者虚拟机还存在快照。
虚拟机磁盘压缩注意事项
压缩前必须关闭虚拟机
所有压缩/转换操作都要求虚拟机处于关机状态，VMware的vmware-vdiskmanager -k在虚拟机运行时执行会报错；qemu-img转换在虚拟机运行时会产生不一致状态，务必先正常关机,再执行压缩。
预留足够的临时空间
qemu-img convert和virt-sparsify会生成一个新的镜像文件，需要占用磁盘空间，执行转换前，确认宿主机至少有镜像文件大小一半以上的可用空间，如果空间不足,可以考虑挂载一块临时硬盘作为中转。
快照与压缩水火不容
存在快照时，虚拟机磁盘由基础磁盘和快照差分盘组成，直接对基础磁盘执行压缩操作，快照数据会丢失，正确步骤是：先删除或合并快照，再执行清零和压缩，合并快照后，虚拟磁盘大小通常会先增大,再通过压缩操作恢复。
磁盘碎片问题
长时间使用后，虚拟磁盘文件内部会形成大量碎片，清零后的数据块虽然内容为零，但分布零散，压缩工具需要重新排布数据，这一步耗时较长，属于正常现象，在机械硬盘上压缩一个40GB的虚拟磁盘，耗时可能在30分钟到数小时之间,SSD上时间会缩短不少。
虚拟磁盘瘦身适合哪些场景
- 开发测试环境：反复创建删除测试数据后，虚拟磁盘膨胀明显,瘦身能回收大量宿主机空间。
- 模板镜像：制作黄金模板前执行一次清零+压缩，部署新虚拟机时文件体积更小,传输更快。
- 迁移上云：把本地虚拟机迁移到云平台前，压缩虚拟磁盘能显著缩短上传时间,降低流量成本。
- 长期运行的业务虚拟机：数据库日志清理或应用日志归档后,执行瘦身可以避免虚拟磁盘持续膨胀。
需要注意，虚拟磁盘瘦身不是常规运维操作，不需要频繁执行，每季度或半年执行一次即可,过度压缩反而增加IO负担。
常见问题解答
虚拟机磁盘缩小后空间未释放，直接删除vmdk文件能找回空间吗？
不能，虚拟磁盘文件与虚拟机配置是一一对应的，直接删除vmdk等于删除整个虚拟机的数据盘，如果只是想回收空闲空间，正确做法是完成清零后执行压缩命令，让vmdk文件本身变小,而不是删除文件。
为什么执行了sdelete和vmware-vdiskmanager -k，磁盘空间还是没释放？
sdelete清零后，vmdk文件大小在宿主机上不会立即改变，必须在关闭虚拟机的状态下执行压缩命令，如果压缩后文件大小依旧没有变化，检查是否存在快照，有快照的情况下，压缩操作会失败或只压缩基础磁盘部分，删除快照后再执行一次压缩，确认磁盘类型是否动态分配,固定大小的虚拟磁盘执行压缩不会缩小文件。
虚拟机磁盘压缩会导致数据丢失吗？
按照正常流程操作不会丢失数据，清零阶段只在客户机内部覆写已删除文件所在的数据块，不影响现存文件；压缩阶段只是重新排列虚拟磁盘的映射关系，但为保险起见，执行前建议对虚拟机做一次完整快照或文件级备份，据VMware官方文档记载，压缩过程会校验块映射，操作中断时优先尝试恢复，即便如此,涉及重要数据时备份仍是第一原则。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/756598.html
