给VMware里的Ubuntu虚拟机扩容看起来是个简单活儿但你要是没搞清楚LVM的机制就动手八成会踩坑。之前帮同事处理过一台跑着业务数据的Ubuntu服务器磁盘明明在VMware里已经从50G加到80G了系统里df -h一看还是原来的50G折腾了半天才理清楚LVM那一层的逻辑。这篇文章就来完整梳理一遍给VMware里的Ubuntu虚拟机扩容的全过程核心针对LVM分区方案从VMware侧的操作到Ubuntu内部的PV、VG、LV一步步扩容全程可复现适合正在被磁盘空间不够困扰的运维、开发者和虚拟化平台管理员参考。文章里我会按实际动手的顺序来讲把每一条命令、每一个输出背后的含义都拆开说明确保你看完不需要再翻别的教程。1. 扩容前的准备工作与核心原理1.1 LVM到底是什么为什么需要先懂它LVMLogical Volume Manager逻辑卷管理器是Linux下解决磁盘分区弹性扩展问题的机制。传统分区方案里一个分区建好之后很难直接扩大比如你用fdisk把整个磁盘分成了/dev/sda1和/dev/sda2之后发现根目录空间不够想从另一个分区挪点空间过来基本得备份、删分区、重建分区再还原数据风险高、时间长。而LVM在物理磁盘和文件系统之间加了一层抽象先把物理分区或整块磁盘做成物理卷PV再把多个PV聚合成一个卷组VG最后从VG里划分出逻辑卷LV文件系统直接挂在LV上。这样一来当空间不够时你可以在线添加新的PV到VG再扩大LV和文件系统甚至不用停机。很多人一听LVM就觉得麻烦但只要你理解了这几个缩写之间的关系实际上操作起来比传统分区更灵活。打个比方传统分区就像你租了一间固定面积的小办公室签了合同就改不了想扩大只能换房子重新装修LVM则像是租了一个可以灵活调整的仓库你觉得货多了可以让管理员在仓库边上再接一块空间然后隔断往里推一点你的储物间就变大了货不用挪。这就是LVM的核心价值。在扩容之前先要在终端里确认你的系统确实使用了LVM。执行lsblk如果输出中出现了vg字样或者执行pvs、vgs、lvs能正常列出内容说明系统确实走了LVM方案。多数Ubuntu Server版本在安装时如果选择了使用整个磁盘并配置LVM或者手动分区时勾选了LVM就会采用这种方式。但也有不少教程或云镜像使用了传统分区这决定了后续的操作路径完全不同。1.2 扩容前的必备检查清单别急着关机去点VMware的扩展磁盘按钮先花几分钟把下面几项检查做了能避免大部分扩容失败的意外。第一确认当前磁盘设备名。多数VMware虚拟机使用的是SCSI虚拟磁盘设备名一般是/dev/sda但也有可能是/dev/nvme0n1或/dev/vda取决于虚拟化配置。执行lsblk可以一眼看到你的磁盘设备和所有分区、LVM逻辑卷的关系例如$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 50G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 49G 0 part │ └─ubuntu--vg-root 253:0 0 49G 0 lvm /请注意这里sda总大小还显示50G是因为我们尚未在VMware侧扩展如果已经扩展过大小会显示为新值。设备名在后边的命令中会反复用到搞错设备名轻则命令无效重则可能影响数据。第二确认逻辑卷路径。从lsblk可以看到逻辑卷名称可能是ubuntu--vg-root对应的设备节点一般是/dev/mapper/ubuntu--vg-root而/dev/ubuntu-vg/root是指向同一设备的符号链接。执行lvs可以列出所有逻辑卷和它们的路径后续lvextend和resize2fs都要用到这个路径写错任何一个字符都会报错。第三备份重要数据。别嫌麻烦生产环境最好先在VMware里打一个快照或者至少把关键数据库、配置文件拷贝出来。扩容操作本身虽然设计为在线、非破坏性但万一断电、误输入或VMware层面出问题有备份才有后悔药。第四确认当前文件系统类型。LVM逻辑卷上可能是ext4也可能是xfs不同文件系统扩容命令不同ext4用resize2fsxfs用xfs_growfs。执行df -hT可以看到根挂载点的文件系统类型比如$ df -hT / Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-root ext4 49G 45G 2.0G 96% /这里Type为ext4意味着后续要执行resize2fs。如果显示xfs则最后一步要换命令我后边会单独说明。第五搞清楚当前的卷组容量和使用率。执行vgs或vgdisplay看看卷组里还有多少空闲空间VFree这样在扩容完成后你就知道新空间是否成功融入了卷组。例如$ sudo vgs VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 2 0 wz--n- 50.00g 0VFree为0说明卷组当前没有任何空闲空间磁盘空间确实被瓜分完了扩容需求很合理。2. VMware侧磁盘扩容操作2.1 在VMware Workstation里扩展虚拟磁盘大小VMware侧的操作步骤在不同产品上略有差别但思路一致。以VMware Workstation为例先关闭虚拟机或者保持开机状态Workstation支持对正在运行的虚拟机扩展磁盘但部分系统版本可能需要重启才能识别新空间后面会讲右键虚拟机标签选择设置Settings在硬件选项卡里找到硬盘Hard Disk右侧可以看到磁盘大小Maximum size默认是灰的点击扩展Expand按钮后填入你想要的最终磁盘大小。这里有一个非常关键的认知扩展磁盘大小是指最终大小而不是增加大小。比如原本是50G你想加到80G就在输入框里填80不是填30。Workstation会把磁盘文件从50G扩容到80G。需要注意的是VMware的磁盘扩展是只增不减的一旦扩容无法直接缩回去所以建议一步到位多预留一些余量避免过一两年又不够用。我在实际项目中一般会按未来1-2年数据增长速度做估算宁可多扩一点也不折腾第二次。如果你的虚拟机是vSphere/ESXi环境操作路径是在vSphere Client中选中虚拟机右键编辑设置找到硬盘把硬盘大小改为目标值然后确定。这步操作在vSphere中也可以在线完成但底层操作同样是增大虚拟磁盘的容量上限。无论哪种管理平台虚拟磁盘扩容本身不会破坏现有数据因为这是在磁盘尾部追加空闲空间原分区和文件系统完全不受影响。提示如果虚拟机有多个虚拟磁盘一定要确认你扩展的是正确的那个磁盘。看虚拟机设置里磁盘的SCSI编号比如SCSI 0:0通常对应系统内的/dev/sda扩展前先用lsblk确认一下设备名避免把数据盘和数据盘搞混了。2.2 虚拟机内部确认新空间是否可见扩展完虚拟磁盘后启动虚拟机进入Ubuntu。此时执行lsblk你应该能看到磁盘总大小已经变成了新值比如原先的50G变成了80G但分区大小和逻辑卷大小不变VFree仍然是0df -h也还是旧空间占用状态。这是一个很正常的空间已经到达磁盘层但还没分配到分区/LVM的状态。如果你在lsblk中看到的仍然是旧大小通常有两种原因一是虚拟机在开机状态下扩展的磁盘某些Linux发行版需要重启一次才能识别到磁盘的新容量二是在vSphere环境下客户机操作系统需要执行echo 1 /sys/class/scsi_device/*/device/rescan或重新扫描SCSI总线来感知磁盘变化。对于Ubuntu Server最稳的办法是重启一次因为后续操作涉及的fdisk、pvcreate等命令需要内核正确识别新容量重启成本低收益明确。我习惯在扩容后先重启一次再执行lsblk确认。如果确认磁盘总大小正确显示为新值就可以进入下一节的分区与LVM扩展操作了。还有一种情况需要提醒如果你使用的是整块磁盘直接创建PV而不是分区后再创建PV那么可能在扩容磁盘后还需要执行sudo pvresize /dev/sda来让PV感知新容量这种情况下通常不需要新建分区。但Ubuntu安装器默认方案通常是在物理分区上建PV所以下面我按新建分区-新PV-扩展VG-扩展LV-扩展文件系统这条最通用的路径来演示。3. 在Ubuntu中扩展LVM分区的完整实操3.1 创建新分区并制作物理卷进入系统后先用lsblk确认磁盘新容量已生效。假设现在是$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 80G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 49G 0 part │ └─ubuntu--vg-root 253:0 0 49G 0 lvm /可以看到sda总大小已经是80G但/dev/sda2还是49G后面大约30G未分配。现在我们要把多余的空间划分成一个新分区。使用fdisk操作磁盘sudo fdisk /dev/sda进入交互模式后按顺序操作输入n新建分区。此时fdisk会询问分区类型默认是p主分区。如果磁盘分区表是MBR且主分区数量已经满了fdisk可能会提示你用扩展分区e这时就输入e创建扩展分区再在里面创建逻辑分区。如果你的磁盘是GPT格式Ubuntu Server默认通常是GPT则不会有这个限制。分区编号按提示确认即可比如下一步是3那么新分区就是/dev/sda3。起始扇区直接回车使用默认值即从磁盘空闲区的起始处开始。结束扇区直接回车使用默认值即使用到磁盘末尾把这个新分区填满所有余量。输入w保存并退出。退出后执行partprobe /dev/sda刷新分区表然后确认新分区已出现$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 80G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 49G 0 part │ └─ubuntu--vg-root 253:0 0 49G 0 lvm / └─sda3 8:3 0 30G 0 part接下来创建物理卷。在创建之前我非常建议先执行wipefs -a /dev/sda3清理掉新分区上可能残留的旧文件系统签名尤其是当这个分区之前被格式化过时。wipefs这个命令很冷门但能避免后边pvcreate报告Device /dev/sda3 not found or ignored之类的问题。然后执行sudo pvcreate /dev/sda3输出类似Physical volume /dev/sda3 successfully created.如果运气不好遇到提示Device /dev/sda3 not a valid LVM PV或Cant open /dev/sda3 exclusively多半是分区表没刷新或设备忙用partprobe刷新一下必要时关掉占用进程或重启再试。注意千万不要在pvcreate时使用整个磁盘设备/dev/sda去覆盖已有PV除非你能确认原来确实是整块磁盘做的PV否则会破坏现有LVM元数据造成数据丢失。正确的做法始终是创建新分区然后把新分区作为新PV加入卷组。3.2 扩展卷组与逻辑卷现在我们已经有了一个全新的物理卷/dev/sda3它还不是卷组的一部分。查看当前卷组信息sudo vgs输出VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 2 0 wz--n- 50.00g 0当前卷组ubuntu-vg只有一个PVVFree为0。现在把新PV加入卷组sudo vgextend ubuntu-vg /dev/sda3成功输出Volume group ubuntu-vg successfully extended再执行sudo vgs查看变化VG #PV #LV #SN Attr VSize VFree ubuntu-vg 2 2 0 wz--n- 80.00g 30.00g此时卷组的总容量已经从50G变成80GVFree为30G。如果你在这一步看到的VFree还是0说明vgextend没执行成功检查命令是否拼写错误、PV是否正常创建。接下来扩展逻辑卷。先执行lvs看看有哪些逻辑卷$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao---- 48.75g这里主要关注根逻辑卷root。要把它扩展到卷组所有空闲空间执行sudo lvextend -l 100%FREE /dev/ubuntu-vg/root-l 100%FREE的意思是使用卷组中100%的空闲物理扩展块PE把根逻辑卷扩到最大。你也可以用更直观的-L 30G来指定增加30G但我个人更推荐-l 100%FREE因为这样能省去计算而且不用担心空间浪费。执行后输出类似Size of logical volume ubuntu-vg/root changed from 48.75 GiB (12480 extents) to 78.75 GiB (20160 extents). Logical volume ubuntu-vg/root successfully resized.如果逻辑卷路径不确定可以用sudo lvdisplay查看确切LV路径或者直接使用/dev/mapper/ubuntu--vg-root。有些系统逻辑卷名是ubuntu-lv对应的路径是/dev/ubuntu-vg/ubuntu-lvlsblk会直观显示这个对应关系。在这一步结束后其实lvextend已经扩展了逻辑卷但文件系统还来不及知道。此时如果你执行df -h看到的仍是旧空间接下来要做的就是让文件系统也听懂新空间。3.3 扩展文件系统让空间真正可用扩展文件系统这一步要区分文件系统类型。前面已经说过ext4使用resize2fsxfs使用xfs_growfs。对于ext4文件系统执行sudo resize2fs /dev/ubuntu-vg/root输出resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/mapper/ubuntu--vg-root is mounted on /; on-line resizing required old_desc_blocks 7, new_desc_blocks 10 The filesystem on /dev/mapper/ubuntu--vg-root is now 20643840 (4k) blocks long.然后df -h验证$ df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-root 78G 45G 29G 61% /根目录已经变成78G扩容成功。注意df -h显示的是逻辑卷的实际容量因为逻辑卷元数据是80G但文件系统本身是78.75G左右去掉一部分文件系统保留块所以显示78G是很正常的不用纠结。如果你遇到的是xfs文件系统命令则是sudo xfs_growfs /xfs支持在线扩容且不需要指定设备路径它会自动检测挂载点所在的文件系统。输出类似meta-data/dev/mapper/ubuntu--vg-root isize512 agcount4, agsize6553600 blks sectsz512 attr2, projid32bit crc1 finobt1, sparse1, rmapbt0 data bsize4096 blocks26214400, imaxpct25看到blocks数字变化了说明文件系统扩展成功。最后再对卷组和逻辑卷做一次全量确认sudo vgs sudo lvs lsblk df -h这四个命令一眼扫过去整个扩容链条就全部清楚了。如果你在lsblk中看到sda3对应的LVM路径并且df -h显示新容量说明整个流程圆满结束。有些系统可能需要重启一次文件系统才能正确显示新容量但一般ext4在线扩容即刻生效重启只是帮助系统更干净地显示。4. 常见问题与排查技巧实录4.1 在fdisk中看不到新空间怎么办扩容后最常遇到的一个问题就是fdisk /dev/sda进去后看不到磁盘新容量系统里显示的还是旧大小。碰到这种情况先不要怀疑VMware扩没扩成功按顺序排查。第一个可能性是虚拟机开机状态下扩展了磁盘Linux内核没有实时感知到SCSI设备大小的变化。解决办法是重启虚拟机或者在线重新扫描SCSI总线echo 1 /sys/class/scsi_device/0:0:0:0/device/rescan实际路径以ls /sys/class/scsi_device/输出为准。如果设备名是/dev/sda通常对应的SCSI路径是0:0:0:0或类似。这个办法在大部分现代Linux内核中有效但如果重启成本不高我还是推荐直接重启最省事。第二个可能性是在fdisk交互界面里看到了新大小但partprobe /dev/sda之后lsblk还是没有新分区。这种情况多半是分区表被缓存或磁盘忙。可以先退出fdisk执行sync再partprobe如果还不行重启一次让分区表重新加载。第三个可能性是fdisk显示了新大小但你需要用parted查看空闲空间。在某些情况下fdisk默认视图会把空闲空间显示为Free Space按p打印分区表可以看到。只要能看到空闲空间说明磁盘层正常直接新建分区即可。我在实际项目里还遇到过一种隐蔽情况fdisk里看不到新空间但parted /dev/sda print free能看到磁盘末尾有Free Space。这通常与fdisk的显示逻辑有关不代表磁盘没扩容。用parted或gdisk也可以看到不必死磕fdisk。4.2 resize2fs报错或空间未生效怎么处理resize2fs这一步是很多人最容易卡住的环节常见报错有几类。第一类错误是Couldnt find valid filesystem superblock或Bad magic number in super-block while trying to open。这通常意味着你指定了错误的设备路径比如把逻辑卷路径写成了/dev/ubuntu-vg/root但实际LV名称并不是root。回看lsblk和lvs确认准确路径。在Ubuntu Server中LV名可能是root、ubuntu-lv或自定义名称直接使用/dev/mapper/ubuntu--vg-root这种在df -h里显示的路径通常是最稳的。第二类错误是执行resize2fs后提示Filesystem at /dev/xxx is mounted on /; on-line resizing required然后没有任何进展。Fine这说明在线扩容受到了限制。解决方法是先卸载再扩容但根文件系统不能随便卸载所以必须在线完成。检查是不是内核或工具版本过老e2fsprogs太老版本对在线扩容支持不好。Ubuntu 18.04及以上的e2fsprogs一般没问题如果是老系统先升级sudo apt update sudo apt install --only-upgrade e2fsprogs第三类常见情况是lvextend执行成功resize2fs也成功但df -h显示的还是旧空间。这可能是shell会话缓存导致df没有刷新。执行sync后重新打开一个终端或者直接执行df -h /再确认。如果确实还是没有变化用dumpe2fs /dev/ubuntu-vg/root查看文件系统的块总数和df对比判断文件系统是否真的扩了。正常情况下resize2fs成功输出Filesystem is now...后df肯定会随之更新。还有一种极为隐蔽的情况你扩展的LV并不是根文件系统挂载的那个LV。比如系统里有/var、/home单独挂了逻辑卷你扩展了A逻辑卷却以为df -h /会变大。所以扩容前必须用df -hT明确确认哪个挂载点对应哪个逻辑卷扩展时瞄准目标别把数据卷扩了而根卷还是老样子。4.3 只适用LVM分区的边界条件说明标题里特别标注只适用LVM分区是因为这套流程有一个严格的前提你的系统必须是通过LVM管理的分区结构。那么怎么判断你的系统是否适用最简单的办法是lsblk如果输出中有lvm字样并且根文件系统挂在/dev/mapper/...上说明适用。如果根文件系统直接挂在/dev/sda1、/dev/sda2这样的物理分区上那这套流程并不能直接解决你的问题。传统分区的扩展路径要麻烦得多常见做法包括使用growpart或fdisk扩展物理分区本身然后扩展文件系统。但对于根分区你没法在分区挂载状态下修改其边界通常需要用live CD或USB启动系统在脱机状态下删除分区再重建并扩大最后再固定文件系统。显然这比LVM方案风险高得多也很容易把引导搞坏。正因如此越来越多发行版默认采用LVM升级空间时只需要加一块新PV或者扩展现有PV完全在线完成这也是我在文档里反复强调LVM价值的原因。另一个边界条件是虚拟磁盘的分区表类型。如果你的磁盘是MBR分区表且已经存在4个主分区此时无法再创建第5个主分区需要先创建扩展分区extended partition再在扩展分区里创建逻辑分区。GPT分区表则没有4个主分区的限制可以随意创建新分区。Ubuntu Server 20.04及以后版本在默认安装时大多采用GPT但如果你升级自旧系统仍可能是MBR。创建分区时如果fdisk提示Primary partition not allowed之类的信息就说明你遇到了MBR主分区数量限制这时候选择类型e创建扩展分区即可。不过要注意扩展分区内的逻辑分区同样可以用于PV不会有性能问题。再说一种不需要新建分区的特殊情况如果当初安装系统时是直接在一块物理磁盘上做PV没有经过fdisk分区这一步那么扩容VMware磁盘后你只需要执行sudo pvresize /dev/sda让PV感知新增的空间然后照常lvextend和resize2fs。判断依据是lsblk里sda直接对应LVM成员还是sda1/sda2等分区对应LVM成员。这两种结构在lsblk输出里差别很明显前者会在sda下直接看到一个属于lvm的分区节点后者会看到sda2等子分区。如果你不确定自己是哪种建议先执行pvs -opv_used看看PV的设备路径如果PV对应的路径是/dev/sda而不是/dev/sda1就说明是整块磁盘方案。最后还要提一个关于磁盘扩容后文件系统是否支持的坑。虚拟机磁盘扩容到一定大小后如果原来的文件系统是ext4它会支持最大1EB理论上所以不存在上限问题。但如果你最初创建文件系统时指定了旧的大小resize2fs默认会扩展到块设备当前大小可能会因为块设备的size变化导致requested size exceeds device size的报错。这种情况通常只在极端场景出现比如逻辑卷没扩到位或者设备映射出了问题。执行lvresize或lvextend时一定要注意逻辑卷最终大小不能超过卷组的VFree总量。4.4 扩容完成后的一些收尾检查成功扩容不代表一切结束。我会在扩容后主动检查三个点。第一确认/boot分区是否有足够的空间因为很多升级操作会用到引导文件/boot空间不足会导致内核升级失败。在LVM扩容场景下/boot通常是独立的小分区不随根逻辑卷扩展所以如果你发现df -h /boot占用率很高需要单独处理。这一步容易被忽略但实际生产环境中不少服务器故障都源于/boot被占满。第二检查定时任务和数据库服务是否正常。resize2fs在线扩容本身不会中断服务但如果你的业务一直在写数据扩容后建议观察一段时间确认服务没有异常。实际操作中我看到过因为扩容后没有同步扩展某个挂载点导致应用还在往旧分区写数据的情况应用日志可能报no space left on device但df -h /却是正常的。原因往往是应用写到了没有被扩容的分区上比如/var被单独挂载了。所以扩容后我会把df -h所有挂载点都看一遍确认没有遗漏。第三检查一下LVM自动激活配置。在Ubuntu里/etc/lvm/lvm.conf中的auto_activation_volume_list可能会影响新PV的激活状态如果配置了白名单新PV可能不会自动加入卷组。当然多数默认配置不需要改动但如果在重启后发现逻辑卷没有激活、根文件系统挂载失败就要想到这个文件。进入救援模式编辑lvm.conf或者直接注释掉auto_activation_volume_list相关行再执行vgchange -ay激活卷组。写在最后扩容这件事最怕的不是命令不会而是对LVM的理解不到位。只要你搞懂了PV、VG、LV、PE这几个概念命令本身记住就很简单。每次扩容前用lsblk把整个磁盘、分区块设备的树形结构截图保存下来比对扩容前后的变化出错时能快速定位是哪一层出了问题。另外再分享一个小技巧如果你经常在多台Ubuntu服务器之间做类似操作可以把df -h echo --- vgs echo --- lvs echo --- lsblk做成一个小脚本一口气输出所有关键信息排查速度能提升一大截。这样一套流程下来给VMware中的Ubuntu虚拟机扩容基本不会翻车。