干运维这行，虚拟机里跑 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 非LVM：gparted图形界面操作
如果你的 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 环境后，找到目标磁盘，如果分区是 ext4，GParted 能直接调整；如果文件系统是 XFS，GParted 的图形界面支持有限，可能要走到命令行，那就需要用到xfs_growfs。但 XFS 本身不支持缩小，只支持扩大，所以扩容这条路还是通的。
操作完成后，重启进入原系统，执行df -h确认/已变大。如果依然没变，八成是你只调整了分区表，没调整文件系统。GParted 正常情况下会一起做，但某些特殊分区布局下可能会遗漏，后续可以用sudo resize2fs /dev/sda2（ext4）或sudo xfs_growfs /来补齐。
3.2 LVM：lvextend加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 用resize2fs，XFS 用xfs_growfs。很多人执行完lvextend觉得完事了，df -h一查没变化就懵了，其实就是少了这一步。
如果文件系统是 ext4：
sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv如果文件系统是 XFS：
sudo 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。
