干运维这行虚拟机里跑 Ubuntu 是家常便饭但基本每隔一段时间就会遇到一次“磁盘满了”的报警。尤其像 Ubuntu 这种系统用着用着Docker 镜像、编译缓存、日志文件就会偷偷把根分区塞满。虚拟机不像物理机插个新硬盘进去还得手动挂载很多人第一反应是“重新装一个”其实完全没必要虚拟磁盘是支持在线扩容的整个流程打通之后十分钟就能搞定。这篇文章我会从宿主机侧的虚拟磁盘文件扩容说起一直讲到 Ubuntu 系统内部分区、文件系统的调整覆盖 VMware Workstation 和 VirtualBox 两个主流平台同时还把 LVM 和非 LVM 两种分区布局都讲清楚。不管你是新手还是老鸟只要能照着下面的步骤走基本不会翻车。适合谁看一类是 VMware 里装了 Ubuntu 做开发环境或测试服务器磁盘不够用了不知道怎么弄的另一类是 VirtualBox 里跑了 Ubuntu想给根分区腾空间又怕把系统搞坏的。甚至可以这么说只要你手里有一个装好 Linux 的虚拟机这篇文章都可以当成一份操作手册来用。1. 扩容前先搞清三件事磁盘结构、备份方式和扩容思路1.1 你的磁盘到底是怎么分区的见过太多人一上来就问我“为什么我把虚拟磁盘调大了系统里还是原来的大小”答案其实很简单你把虚拟磁盘文件调大了但分区表、分区、文件系统都还停在原来的状态系统当然“看不到”新增的空间。所以你需要理解这条完整的链路虚拟磁盘文件vmdk / vdi→ 分区表MBR / GPT→ 分区Partition→ 物理卷 / 文件系统 → 挂载点扩容操作的本质就是沿着这条链路逐级把空间“放大”。如果中间任何一环没做最终在系统里看到的可用空间都不会变。另外Ubuntu 桌面版默认安装时通常用简单的 ext4 分区但服务器版尤其是用 LVM 选项安装的极大概率会走 LVM 布局。这两种布局后续扩容命令完全不同所以第一步一定是先确认自己属于哪种。在 Ubuntu 终端里执行lsblk看到类似下面的输出NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 98G 0 part └─ubuntu--vg-ubuntu--lv 253:0 0 98G 0 lvm /像这种带ubuntu--vg-ubuntu--lv的就是 LVM 布局sda3 被划成了物理卷所有剩余空间都并进了一个逻辑卷。如果你看到的是sda1、sda2直接挂在/和/home而且没有lvm这一层那就是普通分区布局。后面章节我会分别给两套方案。1.2 动手前必须做的备份与三种方案对比扩容操作其实算不上高危但“算不上高危”只适用于已经熟练掌握的人。新手一旦把分区表弄乱虚拟机起不来那时候你就知道备份多重要了。三种备份方案我按推荐程度排个序第一种给虚拟机做快照。VMware Workstation 直接右键虚拟机 → 快照 → 拍摄快照VirtualBox 在“控制”菜单里选“生成备份”。快照是最快的方式缺点是快照文件会占用宿主机磁盘空间而且如果虚拟机本身特别大快照也可能失败。第二种导出虚拟机和拷贝 VMDK/VDI 文件。这种方式需要虚拟机关机然后把整个磁盘文件复制一份到其他目录。好处是独立于虚拟机后续操作再怎么翻车都能恢复缺点是时间久、占空间。第三种只备份关键数据。比如把数据库、项目代码、Docker 数据卷 tar 出来。坦白讲如果你机器上运行的是重要服务这种备份不够安心但总比没有强。我的习惯是生产机器直接整盘导出或先打快照自己折腾的测试环境文件复制一份就足够了。备份不是可选项而是前提条件。1.3 直接扩容还是加新盘怎么选很多人以为“磁盘不够”→“扩容”是一条必然路线其实不是。扩容和加新盘各有适用场景。如果系统是 LVM 布局而且根分区确实有大量的日志、Docker 镜像等历史数据在增长直接扩容虚拟磁盘是最顺手的路子你不需要调整任何挂载关系把物理卷和逻辑卷放大就行。但如果只是/home满了而根分区的空间还很充裕这时候加一块虚拟磁盘、格式化成 ext4挂载到/home反而比扩容更省事也更安全。加新盘的思路是宿主机加虚拟磁盘 → 系统里fdisk分区 →mkfs.ext4格式化 → 修改/etc/fstab自动挂载。整个过程完全不会碰原来的分区风险低得多。所以动手前先问自己一句我到底是根分区满了还是/home满了缺的不是空间而是挂载点的话加新盘会更科学。如果确实要扩容继续往下看。2. 宿主机侧操作VMware和VirtualBox磁盘文件扩容2.1 VMware vmdk 扩容实操VMware Workstation 有两种方式扩容虚拟磁盘图形界面和命令行。图形界面最简单虚拟机关机后打开“虚拟机设置”选中硬盘右侧会出现一个“扩展”按钮输入你想要的总容量比如原来 60GB直接改成 100GB点“扩展”就能完成。这里有个细节写这行命令之前必须先确认虚拟机已经关机。虽然 VMware 声称支持在线扩容某些场景但 Workstation 产品在开机状态下“扩展”按钮是灰的。如果你用的是 vSphere/ESXi 这类商业平台可以热添加不过这篇文章主要针对 Workstation还是老老实实关机操作。命令行方式也不复杂用 VMware 自带的vmware-vdiskmanager工具Windows 下的路径通常是C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe -x 100GB D:\VM\Ubuntu\Ubuntu.vmdk参数-x就是 expand后接目标容量和 vmdk 完整路径。如果你有多个 vmdk 分卷文件只需要指定主文件Ubuntu.vmdk工具会自动处理附属的-s001.vmdk这些分卷。扩容所需时间取决于磁盘大小一般几分钟。还有一个常被忽略的点如果你当初建虚拟机的时候选了“将虚拟磁盘拆分成多个文件”split扩容同样没问题但如果 vmdk 是快照之后的链式结构只要当前快照是当前活动状态就可以直接扩展。如果快照很多建议先把快照合并掉再扩容否则容易出怪问题。2.2 VirtualBox vdi 扩容实操VirtualBox 用的是 VDI 格式扩容命令是VBoxManage。同样需要虚拟机关机然后执行VBoxManage modifyhd D:\VirtualBox VMs\Ubuntu\Ubuntu.vdi --resize 102400注意单位是 MB所以 100GB 就是 102400。如果你当初创建的是动态分配磁盘默认就是这个操作只会把“理论上限”调大不会立即占用宿主机空间。如果你用的是 VMDK 或 VHD 格式VBoxManage 也能处理但 VMDK 格式对 resize 支持偶尔会有兼容性问题遇到报错可以先转成 VDI 再扩容VBoxManage clonehd source.vmdk target.vdi --format VDI另外VirtualBox 6.1 之后也支持在图形界面“存储”设置里直接拖动滑块修改大小但命令行的控制力更强也比较适合写脚本批量处理。我建议你学会命令行因为以后不管是在服务器上管理 VirtualBox 虚拟机还是想自动化扩容命令行都是唯一可靠的方式。2.3 扩容后先别急着进系统确认盘符变化扩容完成后先不要马上打开虚拟机可以先在宿主机侧验证一下虚拟磁盘文件变化。比如 VMDK 用-x扩容后文件大小可能不会立刻变大因为动态分配的特性但描述文件里的虚拟容量已经变了VDI 同理。如果你不确定是否成功可以用vmware-vdiskmanager -d检查容量或者直接看VBoxManage showhdinfo xxx.vdi输出里的容量信息。确认宿主机侧扩容成功后启动 Ubuntu 虚拟机。这个阶段进入系统后df -h看到的容量大概率还是原来的别慌这是正常的因为你还没动分区表。先看一下现在系统层面识别到的磁盘大小sudo fdisk -l /dev/sda如果输出里显示的 Disk size 已经变成了 100GB宿主机侧的扩容就生效了。如果不生效检查是不是容量没变大或者虚拟机里还挂着旧快照。确认这步没问题之后才能进入下一阶段的分区扩容。3. 系统内部分区扩容非LVM与LVM两条路径3.1 非LVMgparted图形界面操作如果你的 Ubuntu 没有用 LVM比如默认桌面版安装那么扩容根分区最稳妥的方式是使用 GParted 图形工具。为什么要用图形界面因为普通分区比如/dev/sda2的边界扩展操作在命令行下用fdisk也能做但需要删掉分区再重建中间任何一步出错就会导致数据丢失。GParted 在这个场景下容错率高很多而且会预告每一步操作新手也不容易误操作。前提是先给 Ubuntu 安装 gparted。如果系统还能进直接执行sudo apt update sudo apt install -y gparted然后启动sudo gpartedGParted 窗口里能看到磁盘的分区布局。假设根分区是/dev/sda2后面还有未分配空间你只需要右键/dev/sda2选择“调整大小/移动”把“新大小”拖到最大然后点击“应用”按钮它就会执行一条“resize2fs 并把分区边界扩大”的操作。有一点我要重点强调这里不能直接调整已经挂载到根目录的分区除非你用的 GParted Live CD 或者启动盘环境。在正常系统里对根分区做 resize百分之百会报“分区正忙”之类的错误。所以如果你是桌面版且根分区就是系统盘正确做法是下载 GParted Live ISO或者使用 Ubuntu 安装 U 盘里的试用环境从该环境启动再来执行上述操作。启动到 Live 环境后找到目标磁盘如果分区是 ext4GParted 能直接调整如果文件系统是 XFSGParted 的图形界面支持有限可能要走到命令行那就需要用到xfs_growfs。但 XFS 本身不支持缩小只支持扩大所以扩容这条路还是通的。操作完成后重启进入原系统执行df -h确认/已变大。如果依然没变八成是你只调整了分区表没调整文件系统。GParted 正常情况下会一起做但某些特殊分区布局下可能会遗漏后续可以用sudo resize2fs /dev/sda2ext4或sudo xfs_growfs /来补齐。3.2 LVMlvextend加resize2fs/xfs_growfs完整命令LVM 扩容本质上分三步先让物理卷PV感知新空间再扩充逻辑卷LV最后让文件系统跟上。这也是很多老手都要背下来的命令序列顺序不能乱。假设你的虚拟磁盘从 60GB 扩到了 100GB原来的物理卷/dev/sda3大小是 60GB现在需要把新的 40GB 加进 PV第一步让 PV 识别新空间sudo pvresize /dev/sda3执行sudo pvs可以确认 PV 的物理大小是否已经变成 100GB。如果 PV 大小没变先检查分区/dev/sda3本身是否已经扩大到新空间。有时候你在宿主机侧扩容了但分区表里 sda3 分区还没扩这种情况在非整盘分区的时候很常见需要先用fdisk调整 sda3 分区边界或者直接重新扫描分区表sudo partprobe /dev/sda第二步扩充逻辑卷。先查一下当前逻辑卷名sudo lvs输出类似LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert ubuntu-lv ubuntu-vg -wi-ao---- 98.00g然后把所有剩余空间都分配给根目录逻辑卷sudo lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv如果你只想加固定大小比如加 20GB可以这样sudo lvextend -L 20G /dev/mapper/ubuntu--vg-ubuntu--lv第三步也是最多人翻车的一步扩充文件系统。注意文件系统类型ext4 用resize2fsXFS 用xfs_growfs。很多人执行完lvextend觉得完事了df -h一查没变化就懵了其实就是少了这一步。如果文件系统是 ext4sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv如果文件系统是 XFSsudo xfs_growfs /为什么 XFS 要挂载点作为参数因为xfs_growfs是 XFS 文件系统专用的在线扩容命令它不读块设备名而是读挂载点所以你必须确保目标分区的挂载点存在且可见。如果挂载点是/home那就是sudo xfs_growfs /home。这里也顺带回答一个很常见的搜索问题“lvextend 扩容之后还要执行什么命令”——还需要执行文件系统级别的扩容命令不执行的话逻辑卷虽然变大了但文件系统依然维持原样空间根本没写进文件系统。执行完resize2fs后用df -h查看根目录的大小就会变成新的容量。至此LVM 扩容全流程结束。3.3 单独/home分区扩容的注意事项很多人在安装 Ubuntu 时手动分区把/home单独分了出去。这种情况其实更简单因为你不需要动根分区只需要扩容/dev/sda4或对应的 home 分区即可。非 LVM 布局下直接在 GParted 里调整 home 分区大小原理和前面一样把未分配空间放在 home 分区前面还是后面记住一点如果你要把根分区后面的空间挪给后面的 home 分区就必须保证未分配空间紧挨着 home 分区的右侧边界或者你先把根分区缩小再把 home 分区扩大——但 ext4 缩小操作有风险且非常慢我不建议没事去缩根分区。LVM 布局下更是方便直接给home对应的逻辑卷扩容sudo lvextend -L 20G /dev/mapper/ubuntu--vg-home sudo resize2fs /dev/mapper/ubuntu--vg-home如果是 XFS 文件系统则执行xfs_growfs /home。还有个小坑如果你只扩容了根分区逻辑卷但系统提示“no space left on device”而df -h显示空间还剩很多那大概率是 inode 用完了不是空间不够。和扩容相反inode 问题通常在创建海量小文件时出现可以用sudo tune2fs -O ^dir_index /dev/sda2之类的命令调整索引但绝大多数场景下你更应该关心的是分区里还剩下的空间能不能满足增长需求。4. 扩容过程中最容易踩的坑和排查方法4.1 为什么lvextend后df -h没变化这个问题我见过太多次了甚至一些工作两三年的运维也会短暂愣一下。原因很简单逻辑卷扩容和文件系统扩容是两件事。lvextend只改了 LVM 层面的元数据让逻辑卷块设备的“长度”变大但文件系统在格式化时就把自己的大小写死在超级块里了它不会主动感知块设备大小变化。所以必须手动执行resize2fs或xfs_growfs来通知文件系统“底下的空间变大了你可以把数据结构扩展过去了”。这个过程是安全的不会破坏数据因为文件系统只是把可用的块范围扩大不会去动已有数据。如果你已经执行了resize2fs但df -h还是没变化还有一种可能文件系统没有干净卸载。比如系统里还有进程占用着这个文件系统或者你没用sync同步。最直接的排查方式sudo resize2fs -p /dev/mapper/ubuntu--vg-ubuntu--lv带-p参数会输出进度如果它提示The filesystem is already N blocks long. Nothing to do!就说明文件系统其实已经扩容过了df没更新的原因可能是你开了某些 LVM 缓存或者/etc/mtab与/proc/mounts不一致重启一下就能解决。4.2 gparted无法调整分区的几种解法在 GParted 里点击分区后“调整大小/移动”是灰色不可用的常见原因有几个。第一新空间根本不在目标分区相邻的位置。比如虚拟磁盘从 60GB 扩到 100GB 后多出来的 40GB 在磁盘末尾但目标分区前面没有任何空闲区域。调整分区的本质是移动边界并重写分区表要扩展一个分区空闲空间必须紧挨着它的后面或者你能接受先把中间的分区整体移动那是另一个更复杂的操作。遇到这种情况最简单的办法是把空闲空间建一个新的分区再把数据和挂载指到新分区而不是强行扩原分区。第二分区被挂载。GParted 对已挂载分区默认拒绝操作尤其是根分区。前文已经强调根分区要在 Live 环境里操作非根分区则可以先umount再操作。第三分区表类型或大小限制。MBR 分区表单个分区最大 2TB如果虚拟磁盘超过这个量级需要用 GPT。如果你的 Ubuntu 装的是 MBR想一步到位扩到 3TB基本没戏必须进行 MBR 转 GPT这属于另一个话题操作前一定再三备份。还有一点GParted 界面提示的“Detected 4 alignment problems”这类警告一般是指分区起始扇区对齐问题如果虚拟磁盘本身没问题可以不用太担心。但为了稳妥起见修改完分区表之后建议用fsck校验一次sudo fsck -f /dev/sda24.3 扩容盘和虚拟机扩容是两码事搜索“扩容”的时候经常有人把“虚拟机扩容”和“扩容盘”混在一起。确实有些 U 盘、移动硬盘号称 1TB实际用h2testw一测才发现是劣质芯片配合修改控制器的假容量这种“扩容盘”是指硬件设备虚标容量属于产品质量问题。而虚拟机扩容完全不一样它是虚拟化平台对虚拟磁盘文件的“上限调整”数据没有真实写入的部分不会占用宿主机空间。动态分配的虚拟磁盘一开始可能只有 40GB但虚拟上限是 100GB当你往系统里写数据它才会再往宿主机物理盘里真实写入。如果你用h2testw这类工具去测一个虚拟机磁盘大概率得到的结果也会很奇怪但这不是“扩容盘”而是虚拟化层级带来的读写特性差异。同时也提一句还有一个老生常谈的热搜词“diskgenius扩容c盘”。DiskGenius 是 Windows 生态里的分区工具如果你想直接在 Windows 下给虚拟机的 vmdk 文件做扩容也可以在 DiskGenius 里打开 vmdk 文件进行分区调整但操作逻辑和 GParted 没有本质区别而且它主要面向 Windows 分区。Ubuntu 虚拟机的场景还是 GParted 或者 LVM 命令更对口。4.4 VMware虚拟机扩容后启动异常等疑难有几次扩容完虚拟机开机直接卡在 BIOS 或者提示“Operating System not found”那基本都是分区表被改坏了。最常见的两个原因一是fdisk重建分区时把分区 ID 或引导标志弄丢了二是扩容前没有正确关机直接在虚拟机关闭状态下使用vmware-vdiskmanager时工具弹出了“磁盘被占用”的警告但你还强行执行了。碰到这种情况先别急着重装系统启动到 Ubuntu Live CD通过 GParted 看看分区表是否还在再用 Boot-Repair 工具修复引导sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt update sudo apt install boot-repair boot-repairBoot-Repair 的“推荐修复”一般都能解决 GRUB 引导问题。如果你确实用了快照也可以直接回滚快照然后换一种扩容策略。另外还有一个常见坑扩容后虚拟机开机特别慢或者宿主机磁盘剩余空间急剧缩小。这通常是因为你在虚拟机里对分区做了大量写入而虚拟磁盘是动态分配的宿主机可用空间不够就会把虚拟机拖到卡死。所以扩容前一定要检查宿主机磁盘剩余空间至少保证要大于虚拟机磁盘文件当前实际占用大小的两倍留足操作余量。有一个技巧值得收藏如果你用 VMware而且虚拟机磁盘文件特别大扩容分区之后可以执行一次磁盘碎片整理和压缩减少虚拟磁盘文件的物理大小。把虚拟磁盘从动态转为预分配后再转回动态也能起到瘦身作用不过这是个很耗时的操作日常没必要频繁做。4.5 实操经验新手建议先练手再上生产给新手的最终建议是不要在你的主力开发机上第一次练扩容。找一个测试虚拟机按照刚才的流程走一遍从 VMware 扩容、GParted 调整到 LVM 命令全流程成功一次之后再对真实环境操作。你能明显感觉到整个过程最“容易翻车”的不是命令本身而是你对分区布局、文件系统类型、挂载状态的判断。我自己踩过的坑里最记忆深刻的一次是在一台跑着 GitLab 的虚拟机上做扩容扩容完忘执行resize2fs等了二十分钟看df -h没变化以为分区写坏了紧张得差点去打快照回滚。后来冷静下来一查文件系统大小没变而已补一句sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv就完事了。可以说这一类问题 90% 都是漏了文件系统扩容这一步。最后再说个小技巧扩容操作结束后最好把磁盘挂载信息、逻辑卷信息、文件系统类型都记录到自己的笔记里。下次再扩容五秒钟就能判断该用哪条命令。不要问我为什么强调记录——你真的会在一年后忘记自己的根分区到底是不是 LVM。