1. 问题场景当你的Ubuntu虚拟机开始“报警”如果你和我一样长期在VMware Workstation里跑Ubuntu虚拟机做开发、测试或者学习那么迟早会遇到这两个让人头疼的问题虚拟机内部空间告急以及宿主机上那个巨大的.vmdk文件只增不减。前者让你在虚拟机里装个新软件都战战兢兢后者则让你的宿主机C盘或D盘日渐“消瘦”最终可能连宿主机系统都运行不畅。这其实是两个相互关联但又独立的问题。虚拟机内部空间不足通常是因为当初分配磁盘时过于“保守”随着系统更新、软件安装、日志累积初始的20GB或40GB很快就不够用了。而宿主机存储占用越来越多根源往往在于虚拟机磁盘文件的“膨胀”机制——默认的动态分配磁盘Thin Provisioned虽然创建时很小但会随着虚拟机使用而不断增长并且几乎不会自动缩减。更棘手的是即使你在虚拟机内部删除了大量文件这个.vmdk文件在宿主机上依然“巍然不动”占着茅坑不拉屎。我最近就刚处理完一台用于深度学习环境搭建的Ubuntu 22.04虚拟机。初始给了80GB结果几个大型数据集和conda环境一下来直接爆满。更离谱的是我在虚拟机里删了30GB的临时数据宿主机上对应的vmdk文件大小丝毫未减白白浪费了宝贵的SSD空间。接下来我就把解决这两个问题的完整思路和实操步骤毫无保留地分享给你。整个过程会涉及虚拟机内部的磁盘扩容、文件系统调整以及宿主机层面的磁盘空间回收需要你仔细操作但跟着做一定能成功。2. 核心策略分而治之先内后外面对这两个问题最忌讳的就是眉毛胡子一把抓。我们必须采用“分而治之”的策略并且遵循“先解决虚拟机内部空间再清理宿主机占用”的顺序。这个顺序非常重要原因在于宿主机磁盘空间的回收其有效性和安全性高度依赖于虚拟机内部文件系统的状态。如果你先尝试在宿主机压缩vmdk但虚拟机内部的文件系统依然是碎片化的、或者已删除文件的空间未被有效释放那么压缩操作要么失败要么效果甚微。所以我们的行动路线图非常清晰阶段一为Ubuntu虚拟机扩容。这是解决“内部空间不足”的根本方法。我们需要在VMware层面扩大虚拟磁盘的“物理”容量然后在Ubuntu内部让操作系统识别并利用这部分新增的空间。阶段二为宿主机释放空间。这是在解决内部需求后对宿主机资源的优化。我们需要在虚拟机内部进行“擦除”操作然后在VMware层面进行磁盘压缩让.vmdk文件瘦身。注意在进行任何磁盘操作前务必为你的虚拟机创建一个完整的快照。这是你的“后悔药”万一操作失误可以瞬间回滚到安全状态。在VMware中右键点击虚拟机 - 快照 - 拍摄快照取个易懂的名字比如“Pre-Disk-Operation”。3. 实战第一步为Ubuntu虚拟机扩容详解扩容听起来有点吓人但其实VMware和Linux的工具链对此支持得非常成熟。我们把它拆解成三个子步骤VMware中扩大虚拟磁盘、Ubuntu内识别新空间、最后调整分区和文件系统。3.1 在VMware中扩展虚拟磁盘容量首先你需要完全关闭Ubuntu虚拟机不仅仅是休眠。然后在VMware Workstation的虚拟机库列表中右键点击目标虚拟机选择“设置”。定位硬盘在硬件标签页找到“硬盘(SCSI)”。你会看到当前磁盘的容量例如“80 GB”。扩展磁盘点击右下角的“扩展”按钮如果按钮是灰色的请检查虚拟机是否已关闭并且该磁盘是否被快照依赖。独立磁盘或链接克隆可能无法扩展。在弹出的窗口中输入你希望扩容到的总大小比如从80GB扩展到120GB。这意味着我们将增加40GB的空间。理解限制VMware Workstation有单个虚拟磁盘2TB的限制但对于绝大多数用户这都绰绰有余。点击“扩展”后VMware会开始一个后台任务。这个过程很快它只是在虚拟磁盘文件的元数据中标记了新的最大容量并没有立即向宿主机申请120GB的物理空间宿主机上的.vmdk文件大小暂时不会变。至此虚拟机的“硬件”磁盘已经变大了。但Ubuntu系统现在还完全不知道这回事就像给电脑换了一块更大的硬盘但还没分区格式化一样。3.2 在Ubuntu中让系统识别扩容后的磁盘启动你的Ubuntu虚拟机。我们需要使用Linux下的“瑞士军刀”——fdisk或parted工具来查看和操作磁盘。打开终端首先查看磁盘情况sudo fdisk -l或者用lsblk命令看得更直观lsblk你会看到类似如下的输出NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 120G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 2G 0 part /boot └─sda3 8:3 0 78G 0 part /注意sda磁盘的总大小已经变成了120G但下面的分区sda3通常是你的根分区大小还是78G。这40G的未分配空间就是我们刚扩容出来的目前处于“游离”状态。接下来我们需要使用parted工具来调整分区表将这未分配空间合并到现有分区中。parted支持在线调整比古老的fdisk更友好。sudo parted /dev/sda进入parted交互界面后输入print free来确认未分配空间的位置。你会看到在某个分区后面有一段“Free Space”。假设我们要扩展sda3分区。输入resizepart 3这里的3是分区编号对应sda3。它会询问结束位置。不要直接输入数字输入100%表示将这个分区扩展到占用所有剩余空间。输入quit退出parted。实操心得使用100%是最安全的方式避免了手动计算扇区的麻烦和出错风险。parted会自动计算最大可用空间。3.3 调整文件系统以占用新增空间分区调整好了但文件系统比如ext4还不知道自己“地盘”变大了。我们需要“通知”文件系统去占据新地盘。首先再次用lsblk确认sda3分区的大小已经变成了118G120G减去sda1和sda2的占用。然后针对ext4文件系统使用resize2fs命令sudo resize2fs /dev/sda3这个命令会检查/dev/sda3分区上的ext4文件系统并将其扩展到填满整个分区。过程是联机进行的无需卸载分区或进入救援模式非常方便。完成后使用df -h命令检查你应该会看到根目录/的可用空间大大增加了。为什么选择ext4和resize2fs在Linux桌面环境中ext4是默认且最稳定的选择。resize2fs是专门用于调整ext2/3/4文件系统大小的工具其在线扩展功能非常可靠。相比之下XFS等文件系统虽然也有在线扩展能力但操作命令不同xfs_growfs且收缩操作非常复杂。对于虚拟机扩容这种几乎只增不减的场景ext4resize2fs的组合是最简单直接的。4. 实战第二步为宿主机回收磁盘空间虚拟机内部宽敞了但宿主机上那个庞然大物般的.vmdk文件还在。我们的目标是让它“瘦身”。这需要虚拟机内部和VMware工具配合完成。4.1 在Ubuntu虚拟机内部“准备”可回收空间VMware的磁盘压缩工具很“笨”它只能识别并压缩那些被虚拟机系统标记为“全零”的磁盘块。如果你只是简单地删除文件这些磁盘块上原有的数据还在只是文件系统标记它们为“可用”而已。因此我们需要主动用零去填充这些空闲空间制造出大片的“可压缩”区域。核心命令是zerofree但操作有门槛。zerofree是一个强大的工具它会遍历文件系统的空闲块并将其写零。但它必须在文件系统未被挂载只读挂载也不行的情况下运行。这意味着我们不能在正常运行的系统中执行它。标准操作流程是重启虚拟机在GRUB引导界面选择“高级选项”进入“恢复模式”。在恢复模式菜单中选择“root - Drop to root shell prompt”。此时根文件系统是以只读方式挂载的。我们需要将其重新挂载为只读确保无写入然后运行zerofree。mount -o remount,ro / zerofree -v /dev/sda3-v参数用于显示进度。这个过程取决于磁盘速度和空闲空间大小可能需要一段时间。然而这里有一个巨大的坑新版本的Ubuntu例如20.04之后的恢复模式其根文件系统可能是一个RAM diskinitrd而并非真正的物理磁盘。你在恢复模式下执行zerofree可能是在对内存盘操作完全无效这是我踩过的最大的坑。更可靠的替代方案使用Live CD/USB。从Ubuntu官网下载一个与虚拟机内系统版本相同或相近的ISO镜像。在VMware中编辑虚拟机设置将该ISO文件挂载到虚拟光驱并设置从光驱启动。启动虚拟机进入Ubuntu Live桌面环境选择“Try Ubuntu”。打开终端安装zerofree工具Live环境通常没有sudo apt update sudo apt install zerofree -y使用sudo fdisk -l或lsblk确认你的根分区设备名例如/dev/sda3。务必确认无误在Live环境中你的硬盘分区可能不会被自动挂载这正好。运行zerofreesudo zerofree -v /dev/sda3为什么不用dd或cat /dev/zero填充空闲空间理论上可以例如创建一个大文件sudo dd if/dev/zero of/zero.file bs1M直到磁盘写满再删除它。但这有两个问题第一你需要有root权限在根目录创建巨型文件第二更关键的是你必须在文件系统挂载状态下操作这可能导致系统缓存、日志等后台进程同时写入你无法保证填充完成后那些“空闲块”真的被零覆盖了。而zerofree在文件系统未挂载时工作能保证原子性和彻底性。4.2 在VMware中执行磁盘压缩当zerofree运行完毕后关闭Live CD环境重启虚拟机正常进入你的Ubuntu系统。现在进行最关键的一步在宿主机上压缩虚拟磁盘。再次完全关闭Ubuntu虚拟机。在VMware Workstation中右键点击该虚拟机 - 管理 - 清理磁盘。或者在虚拟机设置 - 硬盘 - 碎片整理这步可选但建议做- 压缩。VMware会弹出一个对话框显示预计可回收的空间。点击“是”或“压缩”。这个过程VMware会读取.vmdk文件寻找那些全是零的块并将它们从文件中剔除从而减小物理文件的大小。压缩时间取决于磁盘文件大小和可回收空间多少。压缩效果验证完成后去宿主机上找到你的.vmdk文件查看其属性。你会发现它明显变小了可能从之前的120GB预分配最大值缩减到了实际数据占用的80GB甚至更少。重要警告“清理磁盘”和“压缩”操作对于“厚置备延迟清零”或“厚置备立即清零”的磁盘是无效的。这两种格式在创建时就在宿主机上占满了你分配的所有空间。VMware的压缩功能仅对“动态分配”Thin Provisioned的磁盘有效。你可以在虚拟机设置的硬盘摘要中查看磁盘类型。5. 深度解析问题根源与长效管理机制解决了眼前的问题我们更需要理解其根源并建立长效管理机制避免问题反复发生。5.1 动态磁盘Thin Provision的工作原理与陷阱VMware默认使用“动态分配”磁盘这是一个“用多少占多少”的聪明设计。但它有一个关键特性只增不减。虚拟机操作系统写入新数据vmdk文件就增长操作系统删除数据vmdk文件大小不变。这是因为从虚拟机内部看是“删除”但从宿主机硬盘的物理扇区角度看那些数据依然存在只是被标记为“可覆盖”。VMware无法智能判断哪些块是“可安全丢弃”的除非你明确地用零去覆盖它们这就是zerofree的作用。这种机制导致了空间占用只升不降的假象。很多人误以为虚拟机“吃空间”其实是管理策略使然。5.2 除了扩容和压缩还有哪些空间管理技巧日志管理Linux系统日志/var/log是空间杀手。定期清理旧的日志文件。# 查看日志目录大小 sudo du -sh /var/log/ # 使用logrotate工具管理或手动清理谨慎 sudo journalctl --vacuum-time7d # 清理7天前的系统日志包缓存清理APT包管理器会缓存下载的.deb包/var/cache/apt/archives。sudo apt clean # 清理所有缓存包 sudo apt autoclean # 只清理过时的缓存包Docker/容器镜像如果你用Docker它的镜像和容器数据默认在/var/lib/docker非常占空间。定期清理无用的镜像、容器和卷。docker system prune -a --volumes用户缓存用户主目录下的.cache文件夹如~/.cache/pip,~/.cache/mozilla等也可能很大。使用LVM逻辑卷管理在初始安装Ubuntu时选择LVM分区方案。这样未来扩容时你只需要在VMware扩展磁盘然后在LVM层面添加物理卷、扩展卷组和逻辑卷即可无需调整主分区更加灵活和安全。5.3 厚置备与动态分配的终极选择如果你受够了动态磁盘的“虚胖”和定期压缩的麻烦并且宿主机硬盘空间充足可以考虑在创建新虚拟机时选择“厚置备”磁盘。厚置备延迟清零创建时立即占用全部宿主机空间但只在实际写入数据时才进行清零操作。性能较好空间一次到位。厚置备立即清零创建时立即占用并清零全部空间耗时最长但安全性最高且后续无需压缩。厚置备磁盘的缺点是初始占用大但好处是空间管理简单明了宿主机上看到多大就是多大没有“压缩”这个概念。对于生产环境或追求性能稳定、厌恶复杂维护的开发者厚置备是更省心的选择。你可以将旧的动态磁盘通过VMware的“转换”功能编辑设置 - 硬盘 - 实用程序 - 转换改为厚置备但这过程同样需要大量空闲磁盘空间和时间。6. 高阶排错当扩容与压缩遇到意外时即使按照步骤操作也可能遇到意外。这里分享几个我遇到过的典型问题及解决方案。6.1 扩容后parted中看不到未分配空间这种情况通常发生在磁盘使用的是MBR分区表并且4个主分区槽位已满时。MBR分区表只支持最多4个主分区或者3个主分区1个扩展分区内含多个逻辑分区。用sudo fdisk -l查看如果磁盘标识为Disklabel type: dos就是MBR。解决方案将分区表从MBR转换为GPT。这需要借助gdisk工具并且操作有风险务必先备份数据sudo apt install gdisk sudo gdisk /dev/sda在gdisk交互界面输入r进入恢复与转换菜单然后输入g将磁盘转换为GPT格式。转换后你需要重新创建引导因为MBR和GPT的引导方式不同Ubuntu通常使用GRUB2支持GPT这涉及修复UEFI引导或重新安装GRUB过程较为复杂。因此最佳实践是在创建虚拟机时就选择GPT分区表。6.2zerofree运行极慢或卡住zerofree的速度取决于磁盘的读写速度和需要写零的空闲块数量。如果它看起来卡住了耐心等待对于机械硬盘或大容量SSD处理上百GB的空闲空间可能需要数小时。-v参数输出的进度更新可能不频繁。检查是否正确运行在另一个终端或宿主机上通过VMware控制台使用sudo pkill -USR1 zerofree可以向zerofree进程发送信号使其打印当前进度如果它支持。替代方案如果实在无法忍受可以考虑在虚拟机内部挂载一个临时分区用dd或fio工具进行写零填充但这需要更精细的空间规划。6.3 压缩后宿主机空间释放不明显如果压缩效果远低于预期确认磁盘类型再次确认虚拟磁盘是“动态分配”的而不是“厚置备”的。检查快照虚拟机如果存在快照压缩操作可能无法作用于快照链中的基础磁盘。尝试合并或删除不必要的旧快照后再压缩。zerofree可能未完全生效确保你在文件系统未挂载通过Live CD的状态下运行了zerofree。在已挂载的系统里运行是无效的。虚拟机内存交换文件Linux的swap分区或swap文件即使被zerofree写零由于其内容本身是易变的压缩效果也可能不持久。可以考虑在运行zerofree前先禁用swapsudo swapoff -a操作完成后再启用。6.4 扩展分区时resizepart失败报错如果parted提示无法调整分区可能是因为该分区正在被系统核心进程使用或者分区后面紧跟着另一个分区没有连续的空闲空间。对于后者你需要先使用parted的move命令移动后面的分区极其危险务必备份或者考虑使用LVM这种更灵活的卷管理方案。对于前者确保你是在Live CD环境下对未挂载的分区进行操作。处理虚拟机磁盘空间本质上是一场在“便利性”和“可控性”之间的权衡。动态磁盘带来了存储的超分配和灵活性但代价是需要定期的手动维护。而厚置备磁盘则用前期的空间占用换来了后期的管理 simplicity。我的个人经验是对于开发测试环境动态磁盘配合我上面介绍的定期清理和压缩流程是完全可控的。我会在日历上设置一个季度提醒检查主要虚拟机的磁盘使用情况并执行一次“内部清理 - 关机压缩”的例行维护。对于承载重要服务或需要极致稳定性的环境我会在初期就分配足够的厚置备磁盘一劳永逸。记住无论哪种方式定期备份和快照都是你数据安全最坚实的防线。
