企业官网建设流程全解析

把Ubuntu拼成Unbuntu这种事儿，我见得真不少，搜索框里随手一敲也难免。上次有人问我：虚拟机磁盘要满了，系统都快拖不动了，有没有什么超简单的办法扩容？我的回答是：能，而且核心逻辑就两层——先把虚拟磁盘文件在宿主机上撑大，再进Ubuntu 22.04系统里把分区和文件系统跟着扩大。这套流程走快了几分钟就能完事。这篇文章就把完整过程拆开写清楚，传统分区和LVM两种最常见的安装方式都会覆盖，并且把这一步一步里最容易翻车的位置都给你标出来。

如果你手里正有一台磁盘吃紧的Ubuntu 22.04虚拟机，不想重装系统，也不想迁移数据，这篇文章刚好对路。下面按我的实际操作顺序来讲，从识别分区方案到最后验证容量，全部是我自己跑过的流程。

1. 先看分区方案：LVM还是传统分区，决定后面怎么操作

1.1 同样一句话"扩展存储"，两套系统命完全不同

很多教程拿到虚拟机扩容就直接教人敲resize2fs，结果有人成功、有人失败，原因十有八九是没搞清系统使用哪种分区方案。Ubuntu 22.04在安装时如果选了"整个磁盘自动分区"，通常是传统方案，根目录直接挂在一个物理分区上；如果安装的是Server版或者手动选了LVM，那根目录会挂在一个逻辑卷上，底层还套着物理卷和卷组。

这两种方案的扩容路线差异很大。传统分区是"扩展分区→扩展文件系统"两步；LVM则是"新建分区→创建物理卷→扩展卷组→扩展逻辑卷→扩展文件系统"五步。如果一开始就判断错了，后面执行命令时多半会报错，或者你折腾半天，发现df -h里的可用空间纹丝不动。所以我坚持在动任何命令之前，先花十秒钟判断清楚。

1.2 三条命令，十秒判断出你的系统类型

在Ubuntu 22.04虚拟机里打开终端，执行下面三组命令：

lsblk df -hT pvs 2>/dev/null || echo "系统未使用LVM"

看输出就能得出结论。第一组lsblk会显示磁盘和分区的树状结构；第二组df -hT会显示每个文件系统的类型和挂载点；第三组pvs如果有输出，说明系统里已经存在LVM物理卷。

判断要点是这样的：如果df -hT里根目录挂载点对应的是/dev/sda2、/dev/sda3这类名字，而且lsblk里完全看不到mapper、vg、lv这些字样，那就是传统分区方案。比如我第一次处理的那个桌面版，输出长这样：

sda 8:0 0 120G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi └─sda2 8:2 0 79G 0 part /

sda总容量已经到120G了，但sda2只有79G，这说明宿主机侧扩容已完成，新空间还没给到分区，下一步就很明确。

反过来，如果lsblk里出现了这样的结构：

sda 8:0 0 150G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi └─sda2 8:2 0 49G 0 part └─ubuntu--vg-ubuntu--lv 253:0 0 49G 0 lvm /

只要看到ubuntu--vg-ubuntu--lv、mapper、lvm这些关键词，就是LVM方案。后面对应的操作路线完全不同，别混着用。

2. 宿主机层面把虚拟磁盘"撑大"

2.1 先关虚拟机再动磁盘，这条顺序别打破

不管用的是哪款虚拟化软件，扩展虚拟磁盘的第一步永远是关闭虚拟机，不是挂起，不是休眠，而是完全关机。这一点必须守住。

虚拟磁盘文件在虚拟机运行期间被句柄占用，这时候强行改大小，轻则界面报错，重则镜像元数据不一致，后续引导都可能出问题。我有一次图省事，直接在虚拟机开着的时候尝试扩展，结果管理界面弹了错误提示，虽然数据没损坏，但也足以让新手吓出一身汗。正确做法是：先在虚拟机里执行sudo shutdown now，等系统完全退出，同时在虚拟化平台里确认虚拟机的电源状态是"已关机"，再做下一步。

2.2 图形界面和命令行，两种扩盘操作实例

如果你用的是常见图形化虚拟机软件，比如VMware Workstation或者VirtualBox，操作基本都在"设置"里：

• VMware Workstation：选中虚拟机 → 编辑虚拟机设置 → 硬盘 → 实用工具 → 扩展 → 输入目标大小。
• VirtualBox：管理 → 虚拟介质管理器 → 选中磁盘 → 属性 → 调整大小 → 拖到目标值。

这里有个容易踩的坑：如果虚拟机有快照，某些版本会拒绝扩展，或者提示磁盘被快照锁定。遇到这种提示，先把不用的快照清理掉，再重新扩展。

如果你更习惯命令行，VirtualBox可以用VBoxManage：

VBoxManage modifyhd /path/to/ubuntu.vdi --resize 153600

注意单位是MB，150G就是153600MB。KVM/QEMU环境则用qemu-img：

qemu-img resize /path/to/ubuntu.qcow2 150G

qemu-img里单位直接写G就行。执行前最好先qemu-img info看一下当前格式和实际大小，确认路径没有写错。

2.3 扩展后先别急着高兴：确认新空间真的到了虚拟机里

扩完盘、启动虚拟机后，先跑一遍lsblk看你磁盘的总容量是否已经变成目标值。比如原来的sda是80G，扩展后应该显示120G或者150G。这步是分水岭：如果总容量变了，说明宿主机侧操作成功，后面所有工作都在系统里完成；如果总容量还是老样子，说明问题出在宿主机侧，赶紧回上一节检查有没有快照、有没有选错磁盘文件，而不是继续在系统里敲命令。

有一点可以放心：虚拟机磁盘扩展后，新空间在虚拟机内部是一段"未分配区域"，不会立刻占用宿主机硬盘的物理空间。qcow2这类动态增长格式的镜像尤其如此——它是用多少占多少，所以扩展后宿主机磁盘并不会瞬间被填满。

3. 传统分区方案的在线扩容：growpart加resize2fs，一步到位

3.1 为什么我不建议手动删分区重建

在growpart这类工具普及之前，大家扩展传统分区都是这么干的：fdisk进入分区表，把原来那个分区删掉，再重新建一个更大的分区。这个操作看着简单，实际风险极高。

最大的坑在于起始扇区。fdisk重建分区时，如果起始扇区跟原来不一样，哪怕只偏移了一丁点，文件系统的元数据位置就对不上了，数据直接"消失"。所以我这里强烈不推荐新手手动走fdisk删除重建的路线，除非你能完全确认分区表的每个细节，并且已经做好了备份。Ubuntu官方云镜像和很多云平台都在用growpart，它做的事情就是自动保留起始扇区、只把分区末尾往后推，从原理上规避了最大风险。

3.2 三步完成传统分区扩容

在确认是传统分区方案后，依次执行：

sudo apt update sudo apt install -y cloud-guest-utils lsblk

cloud-guest-utils里包含了growpart工具。lsblk是为了确认根分区到底在哪个编号上。比如前面那个例子，sda上sda1是EFI分区，sda2才是根分区，那我们操作的对象就是/dev/sda和分区号2。

然后执行growpart：

sudo growpart /dev/sda 2

注意写法：第一个参数是磁盘设备名，不带分区号；第二个参数是分区号，直接写数字。growpart会把分区2的末尾扩展到磁盘的可用末尾。执行完看输出，一般是提示"CHANGED"。

接下来扩展文件系统：

sudo resize2fs /dev/sda2

resize2fs是对ext4文件系统扩容的标准工具，它会把文件系统填满整个分区。执行过程中会显示文件系统当前块数和新的块数，看到这行基本就成功了。最后用df -hT验证：

df -hT

正常情况下会看到根分区的容量已经涨到新磁盘大小，Available列空出了一大截。

3.3 如果你的根文件系统是xfs，命令完全不一样

Ubuntu默认装出来的系统大多是ext4，但如果你在安装时手动选择了xfs，那resize2fs会直接报"Couldn't find valid filesystem superblock"这种错误。不是扩盘失败，是命令用错了。xfs对应的工具是xfs_growfs，而且它是在挂载状态下直接操作即可：

sudo xfs_growfs /

注意xfs_growfs后面跟的是挂载点，不是块设备路径。这一点跟resize2fs完全是两个思维，别弄混。

3.4 实在没装growpart时的fdisk手动路线（备用）

有的精简系统里cloud-guest-utils装不上，或者你拿到手的环境growpart对特殊分区表支持不好，那就只能手动fdisk。这个路线我放在最后当备用方案，操作命令并不复杂，难的是每一步都得确认仔细：

sudo fdisk /dev/sda

进入fdisk交互界面后：

• 输入p，打印分区表，记下根分区当前的Start起始扇区编号，比如2048。
• 输入d，删除根分区。注意别删错分区，建议一个一个看。
• 输入n，新建分区。分区号保持原样，First sector那里直接回车或填入刚才记下的起始扇区编号。
• 输入w，写入分区表。

写入完成后，建议重启一次再执行resize2fs /dev/sda2。整个过程中，起始扇区这个数字是你的保命符，如果生成的起始扇区和原来不一致，马上退出别保存，重新来过。这个方案我只在特殊环境下用，能不动它就不动它。

4. LVM分区的扩展：新分区、物理卷、卷组、逻辑卷四连

4.1 看懂LVM的三层结构，这章就好办了

LVM对刚接触Linux的人有点抽象，我用一个生活化类比帮你看穿它。

PV（Physical Volume，物理卷）就是一块块实体的硬盘或分区，相当于你买回来的一个个仓库；VG（Volume Group，卷组）是把这些仓库统一管理起来的资源池，相当于你租下的一片库区；LV（Logical Volume，逻辑卷）是从这个库区里划出来的一格格仓位，文件系统就建在LV上，相当于你真正拿来堆货的那间库房。

虚拟机磁盘扩大以后，相当于你那个库区旁边多出了一块空地。要做的事就是：在这块空地上建个新仓库（新建分区），把它纳入库区管理（创建PV、加入VG），然后把你真正使用的那个库房扩大（扩展LV），最后让货架间隙变大（扩展文件系统）。每一层都不能跳过。

4.2 第一步：用fdisk把剩余空间变成新分区

进入交互式分区工具：

sudo fdisk /dev/sda

在fdisk交互界面里：

• 输入p，打印当前分区表，顺便确认剩余空间的位置。
• 输入n，新建分区。分区号通常会顺延成3，起始扇区直接回车用默认值，结束位置也回车用默认值，意思就是把这整段剩余空间全部划成一个新分区。
• 输入t，修改刚建的分区类型，把类型改成LVM。MBR磁盘的LVM类型代码是8e，GPT磁盘是30，如果记不清，在fdisk里输L列一下类型表再挑。
• 输入w，写入并退出。

这里有个实用经验：如果磁盘比较大，或者你担心终点位置被系统别的东西占用，可以在fdisk里先输入F查看剩余空间，确认没有异常再写盘。写完以后用lsblk看一眼，应该能看到sda3这个新分区。

4.3 第二步：把新分区变成物理卷并并入卷组

新分区建好后，LVM本身还不认识它，需要先初始化成PV：

sudo pvcreate /dev/sda3

然后看你当前卷组的名字。多数Ubuntu的LVM安装默认卷组叫ubuntu-vg，如果你不确定，用vgs查看：

sudo vgs

得到卷组名后，把新PV加进去：

sudo vgextend ubuntu-vg /dev/sda3

这个阶段可以再用pvs、vgs确认一下状态，你应该会看到VG的可用空间已经出现了大幅增长。这条命令执行完，LVM的资源池已经变大了，但你的根文件系统还没变，因为还需要走到LV这一层。

4.4 第三步：扩展逻辑卷，再扩展文件系统

展示一下逻辑卷当前的路径：

sudo lvs

Ubuntu 22.04 Server的默认逻辑卷路径通常是/dev/ubuntu-vg/ubuntu-lv，但lsblk输出里会显示成ubuntu--vg-ubuntu--lv这种双横线写法。这个双横线是LVM里的转义表示，因为它把卷组名里的-转义成了--，实际命令行中我们用单横线的路径也一样能用。

扩展逻辑卷，把这回新加进来的所有空间全部划给它：

sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

如果你只想增加固定大小，而不是全部给完，可以用-L参数，比如-L +50G。但在虚拟机扩容场景下，通常目的就是让根分区尽量变大，直接用+100%FREE最省事。

然后才是真正对文件系统生效的那一步：

sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

如果你用的是xfs，改成sudo xfs_growfs /。最后df -hT确认，根分区的容量应该已经从原来的几十G变成了现在的完整大小。我实际跑过一遍之后，默认输出会从49G直接跳到149G左右，效果非常直观。

5. 这个过程中容易翻车的位置和一份验证清单

5.1 坑一：快照没清理，扩容直接失败或系统识别不了

虚拟化平台里的快照机制保存的是某一时间点的磁盘差异数据，它会锁定磁盘元数据。带着快照去扩展虚拟磁盘，有的平台会直接报"磁盘被锁定"，有的平台界面上显示扩展成功，但虚拟机系统里永远看不到新容量。

我遇到过界面显示成功、实际不生效的情况，当时排查了很久，最后把目光落到快照上，删除快照后重新扩展一次，立刻就好了。所以我的建议是：扩容这类涉及块设备大小的操作，最好在没有任何快照的状态下进行。如果快照里有重要状态，先想办法导出或冗余，再操作。

5.2 坑二：手动重建分区时，起始扇区写错等于全盘事故

这个事情的严重性怎么说都不为过。fdisk里删除重建看着只是一条n命令，但如果你没留意起始扇区，新分区的数据位置和旧分区对不上，文件系统在开机时根本挂不上，数据会表现为"消失"。不是数据真的没了，是文件系统找不到它的元数据。

所以要再次强调：能用growpart解决的不要手动fdisk重建；非要手动时，p输出的Start列一定要原样保留。动手之前，先做备份。哪怕只是把虚拟机目录复制一份到别的盘，也比事后找数据恢复工具要心里踏实得多。

5.3 坑三：扩容之后df -h完全没变化

这是最容易被忽略的一步。很多时候分区表已经扩大了，甚至lvextend都执行了，但df -h还是老样子，原因就是漏了resize2fs。记住一个链条：虚拟磁盘扩大→分区扩大→（LVM物理卷/卷组/逻辑卷扩大）→文件系统扩大。只要卡在最后一步没做，可用空间就是不变的。

如果df -h没变，按顺序排查：先lsblk看分区容量是否变大，再用lvs看逻辑卷是否变大，最后再确认文件系统是否执行了对应的resize命令。按这个顺序走，基本五分钟内能定位。

5.4 一份可以复制的验证清单

最后补一个个人习惯：验证的时候我建议顺带往系统里写一个大文件，比如用dd生成一个1G的临时文件，写完再删掉。这能确认新空间不只是"显示出来"，而是真实可写可用。测试完毕记得清掉临时文件，避免占着新空间好看不好用。

就我自己的经验来说，虚拟机扩展存储这事真正的难点不在命令，而在顺序和判断。只要先确认了分区方案，再按部就班把每一层扩到位，十分钟真不是夸张的说法。熟练之后，这套流程可以复制到各种发行版和虚拟化平台上，多出来的那几个命令用熟了，以后遇到磁盘告急，心里完全不用慌。