虚拟机缩小磁盘后空间没释放，问题多半不在客户机系统，而在虚拟化层：文件系统里删掉的数据，在宿主机看来仍是"写过的块"，只有把这些块真正归零，再让 vmdk、qcow2 或云盘做一次回收动作，容量才会掉下来。
先弄清楚：空间到底卡在哪一层
很多人的第一反应是"我明明删了几十 G 日志，怎么宿主机一点没变"，原因很简单，磁盘空间有三层账本，三层对不上是常态。
三层账本，别再混着看
- 客户机文件系统层：
df -h变小了，说明系统里确实腾出了空间，但这只是"记账"，不等于物理块被清零。 - 虚拟磁盘文件层：vmdk、qcow2、vhdx 这些文件只会变大不会自动变小，里面的块被标记为未使用，宿主机依然认为它们被占用。
- 存储后端层：本地磁盘、iSCSI、FC、分布式存储，各自的回收机制完全不同，精简置备的 LUN 和厚置备的 LUN，走的是两套逻辑。
简单说,客户机删文件 = 图书馆把书从书架上拿走，但书架还占着地方，要真正腾出房间，得把书架也搬走。
快照是最常见的拦路虎
删了快照,容量却没回来，这种情况在运维工单里出现频率很高，快照是写时复制，母盘被锁定后，所有新写入都进 delta 文件，删除快照只是提交操作，合并过程需要时间和额外空间，尤其层级多、快照老了之后，合并可能卡住甚至失败。
判断方法很直接：查看虚拟机的快照树，确认没有残留；查看数据存储里是否存在大量 -000001.vmdk 之类的增量盘，有，就先把合并做完，再谈回收。
厚置备和精简置备，回收策略不一样
| 磁盘类型 | 空间分配方式 | 能否回收 | 典型操作 |
|---|---|---|---|
| 厚置备（Thick） | 创建时一次性占满 | 基本不能 | 只能迁移或重建 |
| 厚置备延迟置零 | 先占空间，写时置零 | 迁移时可转精简 | Storage vMotion |
| 精简置备（Thin） | 按实际写入增长 | 可以 | 零块打洞、磁盘压缩 |
表格摆出来就清楚了：如果你的盘一开始就是厚置备，那再怎么清理客户机，宿主机空间都不会动，这是设计使然，不是故障。
虚拟机缩小磁盘后空间没释放怎么办：按场景对症下药
Linux 虚拟机删了日志，vmdk 反而更大
这是个经典误会,删文件的同时如果还有进程握着句柄，空间根本不会释放，先用 lsof | grep deleted 查出被占用的句柄，重启对应进程（常见是 nginx、java 应用、数据库日志），df -h 才会真正下降。
然后是两个动作,任选其一：
- fstrim 路线：确认虚拟磁盘挂载时带了 discard 支持，执行
fstrim -av，它会告诉底层"这些块不要了"，精简置备盘配合支持 UNMAP 的存储，能直接回收。 - zero 填充路线：老环境更保险，先用
dd if=/dev/zero of=/zero.fill bs=1M把剩余空间写满零，再rm -f /zero.fill，这一步会把未使用块真正写成零，为后续宿主机识别做准备。
Linux 虚拟机磁盘空间不足怎么清理：清理和回收是两件事
里这句话是很多人的搜索原话，但答案要拆开：清理解决"系统报警"，回收解决"宿主机容量"，清理完不回收，宿主机账本照样难看。
清理时优先看这几处：/var/log 下的轮转日志、/var/lib/docker 的镜像层、/tmp 的临时文件、数据库的 binlog 和 WAL，用 du -sh / | sort -rh | head -20 快速定位大户，清理完，记得回到上面的 zero 填充或 fstrim。
Windows 缩卷失败，卡在不可移动文件
Windows 磁盘管理里的"压缩卷"，只能缩到卷中最后一个不可移动文件之后，页面文件、休眠文件、MFT 预留区、系统还原点，都会挡住收缩，常见表现是明明有 50G 空闲，却只能缩 3G。
处理顺序：
- 关闭系统保护,删除旧还原点
powercfg -h off关掉休眠文件- 把页面文件临时移到别的盘或设为无
- 用
defrag C: /X做一次合并，再尝试压缩卷
缩完之后还要做一步零填充,用 Sysinternals 的 sdelete64 -z C:，把空闲块写成零，否则宿主机依然看不到空间释放。
云服务器磁盘缩容价格怎么算，值不值得缩
云上的逻辑和本地不同,多数云厂商的系统盘不支持在线缩容，数据盘缩容通常要求先卸载、打快照、缩容、重新挂载，再扩容文件系统，价格方面，云盘一般按新容量重新计费，缩容后下一个计费周期生效，已支付的包年包月部分不一定退。
所以在云上,先算一笔账：缩容能省的钱，是否值得停机窗口和操作风险，如果只是几个 G 的差距，直接清理加换更小规格的盘，往往更省事，业内专家指出，云盘回收的瓶颈通常不在技术，而在变更窗口的审批成本。
北京地区自建机房托管的老机器
托管机房里的老设备,存储往往是厚置备 LUN，压根没有精简回收的概念，这种情况下，唯一可行的路径是把虚拟机迁到新存储，或者重建虚拟磁盘再把数据拷过去，北京地区不少机房仍在使用早期 SAN 架构，运维人员遇到这类问题，别在客户机里反复折腾，先确认后端存储是否支持 UNMAP。
VMware虚拟机磁盘扩容后怎么缩小：顺序反了会丢数据
扩容容易缩容难,难点在顺序，行业共识认为，缩容的风险远高于扩容，任何一步顺序错，都可能让文件系统直接损坏。
LVM 的正确收缩顺序
- 卸载文件系统,或至少切到单用户模式
e2fsck -f /dev/vg/lv强制检查resize2fs /dev/vg/lv 20G先缩文件系统lvreduce -L 20G /dev/vg/lv再缩逻辑卷pvresize /dev/sdb最后缩物理卷- 重新挂载,
df -h验证
顺序记住一句话：从内往外缩，从外往内扩，反过来就是数据灾难。
XFS 不能缩，只能备份重建
XFS 文件系统不支持缩小，这是硬限制，不是工具问题，遇到 XFS 需要缩容，只能新建一个更小的分区或逻辑卷，把数据同步过去，改 fstab，再删旧的，别信网上那些"XFS 缩容脚本"，大概率是拿数据开玩笑。
宿主机侧的收尾动作
客户机处理完,回到虚拟化层：
- 关机后执行
vmkfstools -K disk.vmdk，对零块打洞，只对精简置备有效 - Workstation 环境用
vmware-vdiskmanager -k disk.vmdk - vSphere 环境可以直接 Storage vMotion 到另一个数据存储，迁移过程会自动丢弃零块
- 迁移前务必确认没有快照,否则合并会拖慢整个流程
一次完整的回收流程清单
压缩成可执行步骤，照着走基本不会错：
- 确认虚拟磁盘是精简置备,厚置备直接跳到迁移方案
- 清理客户机无用文件,处理 deleted 句柄
- Linux 执行 fstrim 或 zero 填充；Windows 执行 sdelete -z
- 删除全部快照,等待合并完成
- 关机,执行 vmkfstools -K 或 vSphere 磁盘压缩
- 观察数据存储剩余容量,确认回收生效
- 需要缩分区时,按文件系统、逻辑卷、物理卷的顺序从内往外缩
近年来不少企业把回收动作写进了月度巡检,原因很实际：一台机器省几十 G，几十台就是几个 T，折算成存储采购预算并不小。
虚拟机磁盘空间回收常见问答
删了快照空间还是不回来，是坏了吗
不是坏了,是合并没完成，快照合并是后台任务，数据量大时可能持续数小时，可以去任务列表查看进度，也可以看数据存储里增量盘是否还在，如果增量盘长期不动，可能是底层存储空间不足导致合并卡住，需要先腾出空间再重试。
精简置备盘一定要关机才能回收吗
用 vmkfstools -K 必须关机，因为它直接操作磁盘文件，如果不方便停机，可以走 Storage vMotion，在线迁移过程中同样会丢弃零块，代价是需要额外的数据存储和迁移带宽。
为什么 Linux 执行了 fstrim，宿主机容量一点没变
三个常见原因：虚拟磁盘挂载时没启用 discard；后端存储不支持 UNMAP 或精简回收；磁盘本身是厚置备，前两个换 zero 填充可以绕过，第三个只能靠迁移或重建，判断顺序是先看挂载参数，再看存储类型，最后看磁盘格式。