企业官网建设流程全解析

虚拟机里的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 size，VMware里可以通过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 Partition（ESP）。如果输出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/sda

lsblk会直接列出磁盘、分区、挂载点。常见的虚拟Ubuntu系统有两类布局：

• 单分区：整个系统装在一个大分区上，比如sda1直接挂载为/。
• LVM布局：系统安装时选了LVM，根文件系统放在逻辑卷里，比如物理分区sda2是PV，上面创建了ubuntu-vg/root逻辑卷。
• 多分区：sda1是/boot/efi，sda2可能是swap或/。

看清楚了再动手，这一步决定后续用哪套流程。

4.2 最简单的情况：根分区后有剩余空间的growpart路线

如果lsblk显示sda1挂载为/，而且新增的空闲区正好位于/dev/sda磁盘末尾，那最简单的做法就是：

安装growpart工具（Ubuntu桌面版通常没预装）：

sudo apt update sudo apt install cloud-guest-utils

然后扩展第1个分区：

sudo growpart /dev/sda 1

growpart做的事情是把指定的分区扩展到磁盘末端的空闲空间。它只会扩大分区边界，不会动分区内的数据，也不会改变文件系统大小。完成后用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_growfs

resize2fs是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管好GPT

MBR时代用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 bs=4M status=progress

然后在这个镜像文件上尝试各种恢复工具，确保原始数据的安全。

最后说点实在的

我在实际扩容里得到的最大体会是：扩容的顺序绝对不能乱——先备份/快照，再在宿主层扩盘，然后在系统里扩分区，最后扩文件系统，每一步都验证ok了再进行下一步。任何一步倒过来，都会带来各种稀奇古怪的启动故障。

如果你的虚拟机从一开始就把磁盘容量规划得大一些，或者直接启用LVM，后期扩容会轻松很多。LVM的方案里，新增空间几乎不影响现有数据，根分区也可以跨越物理磁盘追加，灵活性远高于单分区直挂。这也是很多生产环境服务器选LVM的原因。

如果你现在正面对一个快满的Ubuntu虚拟机，按这篇文章的顺序一步步来，扩容实际上比想象中简单。最怕的就是不分青红皂白拿起磁盘工具乱锯分区表，那才是把简单问题复杂化的开始。