虚拟机里的Ubuntu跑着跑着就不够用了。当初创建虚拟机时图省事只给系统分了40G装了Docker、数据库、编译环境之后/根分区直接亮红灯。这是玩虚拟机的人几乎都会撞上的问题——想给Ubuntu扩容却发现它卡在两个世界的夹缝里宿主层看到的是磁盘镜像文件系统里看到的是分区和文件系统任何一层没理解透扩容都可能失败。这篇文章把我的实操经验按完整流程整理出来覆盖VMware Workstation和VirtualBox两大类虚拟机以及进入Ubuntu系统后最关键的“分区扩展文件系统扩展”步骤适合正在被磁盘空间逼疯的虚拟机用户参考。1. 动手扩容前先把磁盘形态和引导方式搞明白不少人的第一反应是直接在VMware或VirtualBox设置里把磁盘大小调大完事。这么做的结果通常是“空间已经变大但虚拟机里仍然是老容量”因为宿主机把vmdk/vdi文件变大之后Ubuntu看不到没分区的新空间也不会自动去用。扩容是一个两个层面都要操作的工作先在宿主机层面扩大虚拟磁盘再在Ubuntu里把新增空间划入分区和文件系统。动手之前先确认三件事。1.1 动态置备和固定大小决定扩容容不容易虚拟磁盘的创建方式常见两种动态分配thin provisioning和固定大小thick provisioning。动态分配创建时只占用很小物理空间随着虚拟里写入数据慢慢变大。VMware的VMDK默认就是这种VirtualBox的VDI也是。扩容这类磁盘很灵活宿主机上的镜像文件不会因为“扩容设置”立刻增加物理占用只有虚拟机真正写入数据后文件才慢慢变大。固定大小创建时一次性占用指定的物理空间VirtualBox里叫Fixed sizeVMware里可以通过vmkfstools或转换得到。固定大小磁盘扩容后镜像文件会大幅膨胀扩容前要确认宿主机磁盘余量足够。判断方式很简单在VirtualBox主界面选中虚拟机点“设置→存储”看控制器里的磁盘形态VMware里编辑虚拟机设置查看虚拟硬盘类型。如果不确定直接看文件大小也行——vdi/vmdk文件远小于虚拟磁盘标称值多半是动态分配。1.2 BIOS还是UEFI直接影响要不要碰分区表Ubuntu在虚拟机上可以用传统BIOS引导也可以用UEFI引导。两者的分区表类型通常是MBR和GPT。这个区别决定了后面用哪些工具扩展分区。在Ubuntu里执行一条命令就能知道[ -d /sys/firmware/efi ] echo UEFI || echo BIOS如果输出UEFI系统一般是GPT分区表通常包含一个EFI System PartitionESP。如果输出BIOS一般对应MBR分区表。两种情况下都能扩容但GPT的容错性更好而且单块磁盘容量超过2TB时必须以GPT组织。了解这个信息的意义在于扩容分区后分区表发生变化如果引导loader找不到原分区会导致开机直接进GRUB命令行。提前知道引导方式你才知道该去查什么。1.3 快照和备份是扩容的第一道保险最实用的建议扩容前先打快照或者直接复制一份虚拟磁盘文件。快照的好处是随时能秒回滚。但有个很多人不知道的坑VMware里如果虚拟机存在快照直接在界面里扩容磁盘会报错提示“expansion is not supported for virtual machines with snapshots”。之所以会卡住是因为快照链记录着磁盘的增量数据扩容会破坏这个链路。遇到这种情况需要先删除旧快照或把快照整合Snapshot Consolidate再执行扩容。还有一个容易被忽略的点不要只依赖快照。快照文件损坏或空间不足都会让人崩溃。扩容分区这种涉及底层结构的操作我更推荐额外做一份完整备份。最朴素的方法就是关机后把vmdk/vdi文件复制到另一个目录或者用虚拟机的导出OVF/OVA功能。虽然费点时间但真遇到分区表写错导致系统起不来的情况这份备份能救命。2. VMware虚拟机扩容GUI和命令行两条路都走得通VMware Workstation以及Fusion的扩容入口比较友好但还是有好几个细节值得讲清楚。2.1 Workstation图形界面的操作顺序先关闭虚拟机然后进入虚拟机设置找到硬盘点“Utilities实用工具→Expand扩展”输入新容量执行。不同版本菜单位置稍有差异但大体思路一致。需要注意两个点虚拟机必须是关机状态挂起状态不行。输入的有效单位通常是GB填的数字是“最终容量”而不是“增大的容量”。比如原来100G想扩到200G直接填200。扩容过程通常很快因为动态磁盘只是修改了元数据里的“最大容量”字段并不会立刻把宿主机文件撑大。执行完界面显示成功先别急着开机最好顺手做一次磁盘整理。推荐在“Utilities”里找到“Defragment碎片整理”或命令行执行vmware-vdiskmanager -R C:\path\to\your.vmdk这一步会把虚拟磁盘内部的数据重新组织虽然不是扩容必要动作但对后续读写性能有帮助。镜像文件越大耗时越长预期要有心理准备。2.2 用vmware-vdiskmanager调整磁盘在Linux宿主机上很多人不习惯用GUI用命令行其实更直接。VMware默认自带vmware-vdiskmanager工具如果是Linux版本通常装在/usr/bin/vmware-vdiskmanager。核心命令vmware-vdiskmanager -x 200GB /home/user/VM/Ubuntu/Ubuntu.vmdk参数-x表示扩大磁盘容量后面跟目标总大小。路径有空格时务必加双引号否则会莫名生成一堆奇怪文件。执行前记得检查vmware-vdiskmanager对某些类型的VMDK比如2.0版本的split格式可能不友好。如果报错优先用工具先做一次完整性检查vmware-vdiskmanager -R /home/user/VM/Ubuntu/Ubuntu.vmdk另外如果虚拟磁盘有多个split分片比如Ubuntu.vmdk、Ubuntu-s001.vmdk这种实际操作时只要指定主vmdk文件即可vmware-vdiskmanager会自己处理分片依赖。2.3 扩容后别急着开系统先做一次磁盘检查扩容完成后推荐在虚拟机开机前再做个检查因为这类操作偶尔会出现元数据不一致的问题。一种快速检查方式是用Ubuntu安装ISO启动选择“Try Ubuntu”然后在终端里用fdisk -l或lsblk看看系统是否识别到增大后的磁盘容量。如果能到这一步说明宿主机层面已经完成接下来就跳到文章第4部分继续。我不推荐扩容后直接开机进入正常的Ubuntu系统直接开始resize除非你非常确定分区布局简单且没有快照问题。原因很简单如果分区表操作出错系统启动会异常排查起来不如live环境直观。3. VirtualBox扩容VBoxManage是核心GUI只是辅助VirtualBox的扩容和VMware思路类似但命令和注意事项不太一样。3.1 VDI和VHD的格式差异VirtualBox支持多种磁盘格式VDI是原生格式VHD是微软虚拟硬盘格式Windows Hyper-V通用还有VDMK等。扩容前先用以下命令查看介质信息VBoxManage list hdds输出里能看到UUID、文件名、容量上限和实际占用。这个命令很重要因为后续操作建议直接用UUID而不是复杂的路径规避路径转义问题。3.2 VBoxManage modifymedium的实际用法虚拟机完全关机后执行VBoxManage modifymedium disk path_or_uuid --resize 204800--resize后面接的是兆字节MB单位。204800是200GB。要注意别把单位搞错成GB这是很多人会犯的低级错误——填204800GB的结果是直接撑爆宿主磁盘。如果是旧版命令可能会写成VBoxManage modifyhd效果一样新版推荐用modifymedium。执行成功后会看到0%...10%...100%的进度条这个过程通常几秒就结束因为是逻辑扩容不涉及实际数据拷贝。但如果是固定大小VDI宿主机物理磁盘需要一次性腾出空间耗时会明显长。如果你就是不想记命令VirtualBox的新版界面也提供入口File → Virtual Media Manager → Select disk → Size → Apply。这个GUI操作底层调用的还是同一个resize逻辑。3.3 动态分配磁盘扩容后小文件不缩回的说明这里有个VirtualBox特有的现象动态分配的VDI一旦实际增长过扩容并不会让宿主机文件立刻变大就算虚拟机里写满新空间VDI文件也不一定马上膨胀到上限。这是正常的因为VDI采用按需分配策略。还有另一个点VirtualBox对动态磁盘不支持“缩小”shrink操作。如果你想在不重装的情况下把空间缩小官方是不支持的只能通过clone到新的小磁盘或第三方工具来实现比如qemu-img转换qemu-img convert -O vdi old.vdi new.vdi但这属于重置场景不在本次扩容讨论范围内。扩容只往大了走目前没有安全缩小的正规方式。4. Ubuntu系统里的最后一步分区和文件系统一起扩这是最关键的部分。宿主机磁盘容量变大后Ubuntu里依然只有原来的分区表新空间空闲未用。这里的核心任务是把空闲区扩展到根分区所属的分区再让文件系统吃下这些分区空间。4.1 先用lsblk看清自己的分区布局登录进Ubuntu先看系统现在的结构lsblk df -hT sudo parted -l /dev/sdalsblk会直接列出磁盘、分区、挂载点。常见的虚拟Ubuntu系统有两类布局单分区整个系统装在一个大分区上比如sda1直接挂载为/。LVM布局系统安装时选了LVM根文件系统放在逻辑卷里比如物理分区sda2是PV上面创建了ubuntu-vg/root逻辑卷。多分区sda1是/boot/efisda2可能是swap或/。看清楚了再动手这一步决定后续用哪套流程。4.2 最简单的情况根分区后有剩余空间的growpart路线如果lsblk显示sda1挂载为/而且新增的空闲区正好位于/dev/sda磁盘末尾那最简单的做法就是安装growpart工具Ubuntu桌面版通常没预装sudo apt update sudo apt install cloud-guest-utils然后扩展第1个分区sudo growpart /dev/sda 1growpart做的事情是把指定的分区扩展到磁盘末端的空闲空间。它只会扩大分区边界不会动分区内的数据也不会改变文件系统大小。完成后用lsblk确认分区容量已经变大。接下来扩展文件系统。如果文件系统是ext4常见sudo resize2fs /dev/sda1如果是XFS文件系统多数桌面装ext4少数企业模板用XFS需要sudo xfs_growfs /整个流程结束。df -h再看一次根分区容量就已经增加了。4.3 LVM布局下的扩展流程如果lsblk显示类似/dev/mapper/ubuntu--vg-ubuntu--lv挂载在/下sda3是PV那么要多几步先扩展物理卷让PV吃下磁盘上的新空间sudo pvresize /dev/sda3再用vgs查看卷组可用空间然后让逻辑卷占满所有剩余空间sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv最后扩展文件系统sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv这个方案的优点在于灵活PV、LV可以跨盘组合。用LVM时即使根分区不是最后一个分区也不需要移动任何分区只要物理卷变得更大逻辑卷就能扩大。这也是为什么不少有经验的人在装系统时就启用LVM——后期扩容本身只是三条命令的事。4.4 没有growpart时的fdisk手工扩展法有些精简版Ubuntu或旧版系统装不上cloud-guest-utils这时候可以用fdisk手工操作。重点就一句话删除根分区记录再原样重建一个占用更大空间的分区起始扇区必须保持不变最后不要格式化。执行sudo fdisk /dev/sda交互操作流程输入p查看当前分区表记录根分区的编号、起始扇区号和分区类型。输入d删除这个分区假设根分区是1直接输入1。输入n新建分区分区号选择相同编号起始扇区必须保持和原来一致fdisk一般会提示默认值直接回车结束扇区选择默认即磁盘末尾。如果看到系统提示是否移除签名务必选择“No”否则会删除文件系统签名。输入w写盘退出。重启或者执行sudo partprobe /dev/sda让内核重新读取分区表。这时候再用resize2fs扩展文件系统。这里我必须强调一个风险如果根分区不是磁盘最后一个分区而是中间有一个swap分区或其他分区在后面这个简单方法就不适用了。因为空闲新空间在磁盘末尾根分区并不直接挨着它。强行删除根分区重建无法融合中间的空闲区。遇到这种情况最稳妥的方案不是动分区表而是新增一块虚拟磁盘挂到系统里或者考虑在虚拟机上移动分区但移动分区时间很长失败风险也高。4.5 文件系统扩展resize2fs和xfs_growfsresize2fs是ext家族专用。在线扩容ext4很安全不需要卸载分区。但要注意如果只是想“借空间”但又不想调整整个文件系统resize2fs后面也可以跟指定大小。扩容时直接不加参数让它自动扩展到分区大小即可。xfs文件系统有一个和ext4不同的特性xfs不支持缩小只支持增大而且增大时必须挂载后才能执行。命令是sudo xfs_growfs /而不是对块设备执行。这一点容易搞错很多人用resize2fs的惯性思维去扩展XFS报错找不到文件系统魔数才意识到问题。5. 扩容翻车现场分区表修改后启动失败的恢复思路扩容看似成功系统却挂了这种事我遇到过不止一次。与其写完教程就收工不如把几个典型翻车现场和排查思路一起写出来。5.1 改了fdisk起始扇区导致系统起不来最常见的问题是手工fdisk删分区时新建分区的起始扇区填错了导致根分区原来的数据完全错位。系统开头还能找到一个疑似根分区但文件系统读取失败直接进入“initramfs”或“BusyBox”命令界面。遇到这种情况最省事的办法是不要尝试在命令行里修复而是用Ubuntu安装U盘或ISO启动到live环境把重要数据先拷出来再参考之前的备份恢复或者重装系统。这也是我在第1部分反复强调备份的原因——分区错位这类问题是逻辑错误不是简单执行一条fsck就能恢复的。另一个有效经验是在fdisk删除分区之前先用blkid和fdisk -l记录下分区的完整信息尤其是START一栏的数字。如果误删后新分区无法启动还能用同起始值重建分区理论上能恢复分区挂载。但前提是中间没有执行过新建分区导致覆盖写入。5.2 空间没变化不是没扩容成功还有一种情况宿主机显示扩容成功系统里lsblk也看到磁盘总容量变大了但df -h显示根分区还是老样子。原因通常不是没扩容而是漏掉了文件系统扩展这一步。分区扩展让分区边界变大但文件系统元数据里记录的块数量没变所以df看到的始终是旧值。此时只要补执行resize2fs即可。注意resize2fs需确保分区没有挂载冲突但ext4本身就支持在线resize所以开机状态下执行即可。5.3 分区工具的选择parted和gdisk管好GPTMBR时代用fdisk很顺手但现在是GPT时代手工fdisk对GPT的兼容性并不好尤其是带多个保护分区和备份分区表时。更推荐用parted或gdisk。parted交互式也可以resizepart最常用的是sudo parted /dev/sda (parted) resizepart 1 100% (parted) quit这个操作直接扩展分区号1到100%位置比fdisk更安全因为它强制要求分区起始位置不变只调整结束位置。完成后再跑一遍resize2fs即可。如果你的系统还带着/boot/efi分区并且你轻轻动到了那个分区系统会彻底起不来。所以动分区表时我建议只对目标根分区操作不要试图优化EFI分区大小。别给自己找事。5.4 最后的兜底方案live CD进去救数据前面说到的所有方案都失败时进入live环境救数据是最后一根稻草。用Ubuntu ISO启动到桌面打开“Files”一般能直接挂载原来的根分区把/home下面的重要文件拷贝出来或者用rsync搬到另一台机器。如果连分区都无法识别先用lsblk看磁盘是否存在再用testdisk或gdisk尝试恢复分区表。没有把握时不要写盘先做镜像备份比如sudo dd if/dev/sda of/media/ubuntu/backup/disk.img bs4M statusprogress然后在这个镜像文件上尝试各种恢复工具确保原始数据的安全。最后说点实在的我在实际扩容里得到的最大体会是扩容的顺序绝对不能乱——先备份/快照再在宿主层扩盘然后在系统里扩分区最后扩文件系统每一步都验证ok了再进行下一步。任何一步倒过来都会带来各种稀奇古怪的启动故障。如果你的虚拟机从一开始就把磁盘容量规划得大一些或者直接启用LVM后期扩容会轻松很多。LVM的方案里新增空间几乎不影响现有数据根分区也可以跨越物理磁盘追加灵活性远高于单分区直挂。这也是很多生产环境服务器选LVM的原因。如果你现在正面对一个快满的Ubuntu虚拟机按这篇文章的顺序一步步来扩容实际上比想象中简单。最怕的就是不分青红皂白拿起磁盘工具乱锯分区表那才是把简单问题复杂化的开始。