企业官网建设流程全解析

刚接触 KVM 虚拟化的时候，最怕的就是虚拟机磁盘不够用。尤其是跑数据库或者日志服务的虚拟机，磁盘说满就满，一点预告都没有。很多人第一反应是加一块新盘挂载上去，但数据目录已经写满了，再挂新盘还得迁移数据、改路径，麻烦不说，中间一旦出问题，服务全得停。其实换个思路，直接把现有磁盘“撑大”，让系统里的分区和文件系统跟着扩展，整个过程虚拟机不用关机，服务也不用中断，这就是今天要聊的在线扩展磁盘空间。

这是这个系列的第二篇，上一篇主要讲了离线扩容（关机改镜像、开虚拟机再分区），这篇重点放在完全在线的方式上。也就是说，虚拟机的 vdisk 镜像在宿主机的磁盘池里直接变大，客户机里正在运行的服务完全不感知，随后在客户机内部在线刷新分区表、扩展文件系统，整个过程虚拟机不断电、业务不重启。适合的场景包括：数据库磁盘告警、日志分区吃紧、虚拟机的 /home 目录不够用等。如果你有一定的 KVM 使用基础，至少会用 virsh 和 lsblk，那这篇内容可以直接照着操作；如果你是纯新手，建议先把基础命令的文档过一遍，再回来看这篇。

1. 内容整体设计与思路拆解

1.1 为什么需要“在线扩展”

传统思路里，虚拟机磁盘扩容总是伴随着停机。先关虚拟机，用 qemu-img resize 改大镜像文件，再启动虚拟机，进系统用 fdisk 删除分区重建、或者新建分区挂载。这套流程成熟，但问题也明显：对生产环境来说，停机窗口就是业务损失。尤其现在很多服务都是 7×24 在跑，哪怕只有几分钟的断连，都会造成数据不一致或者客户端报错。

在线扩展的核心价值在于：宿主机层面对镜像文件的扩容操作，不影响虚拟机内部运行的进程；客户机内部的分区和文件系统扩展，也不需要重启系统。这背后的关键机制有两个层面。第一，KVM/QEMU 使用的 qcow2 镜像天生支持“动态增长”，当我们执行 qemu-img resize 把虚拟磁盘大小变大时，宿主机只需要修改镜像文件的元数据，告诉它“这块盘现在变大了”，并不需要立刻在物理磁盘上分配那么多空间，所以这个操作几乎是瞬间完成的，对正在运行的虚拟机来说，相当于我们悄悄把后端硬盘换成了更大的，而它的 I/O 完全没被打断。

第二，客户机内部有现代操作系统支持“热插拔”和“在线刷新”。Linux 内核在检测到底层块设备尺寸变化后，会通过 sysfs 更新设备的容量信息。我们用相关命令重新读取分区表，再把文件系统扩展到新的大小，整个链路就打通了。这套流程对 ext4、xfs 都适用，不同文件系统的扩展命令略有差别，但核心思路完全一致。

1.2 在线扩容 vs 离线扩容的取舍

有人会问，既然在线扩容这么方便，是不是所有场景都该用在线？我的看法是分情况看。离线扩容的最大优势是“绝对稳定”，你把虚拟机停在那，随便怎么折腾镜像都不会影响业务，哪怕扩容过程中宿主机 I/O 负载很高，客户机里也不会有任何感知。但缺点是必须有停机窗口。

在线扩容适合的是：业务不允许中断、存储池剩余空间充足、宿主机和客户机的操作系统都能支持在线刷新。不适合的场景也有：比如客户机里是老旧版本的操作系统，内核不支持在线刷新分区表；或者分区方案非常复杂，用了非常规的 GUID 分区表布局；又或者底层文件系统本身不支持在线扩展（某些老旧的加密文件系统）。这些时候强行在线操作，一旦失败可能连系统都起不来，风险大于收益。

从我实际接触的项目看，目前主流的发行版（无论是 Debian 系还是 RHEL 系）都已经原生支持在线扩容，所以在生产环境里，我大多数时候都优先选择在线方式，只有遇到客户机内核太老、或者磁盘上叠加了多层 LVM 快照这种特殊场景，才会退回离线方案。

1.3 整体操作的链路图

在线扩展磁盘空间并不是单条命令就能搞定的，它是一条链路：宿主机扩容镜像 → 客户机扫描新容量 → 调整分区 → 扩展文件系统。每一步都必须按顺序来，不能跳步。比如你只扩大了镜像，但客户机里没刷新分区，那系统看到的还是旧容量；或者你分区扩展了，但文件系统没动，那可用空间还是原样。理解这条链路，比背命令更重要。

下面这张表可以帮助你一眼看清整个链路中每一步的作用：

整个链路每一步都有对应的验证方法，实际操作中最好是“走一步看一眼”，别一口气全做完再检查。因为如果中间某一步失败了，你至少知道是哪个环节出了问题，不至于从头排查。

2. 核心细节解析与实操要点

2.1 先看虚拟机磁盘现状

在动手之前，务必先把当前状态摸清楚。我最常用的方式是：

virsh list --all virsh dumpxml <虚拟机名称> | grep -A2 '<disk>'

第一行确认虚拟机是运行状态还是关闭状态，因为在线扩容的前提是虚拟机正在运行（当然，qcow2 镜像在虚拟机运行时也能扩容，这是在线操作的基础）。第二行能看清磁盘的类型、源文件路径、总线类型。举个例子，一条典型的配置是：

<disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/vm01.qcow2'/> <target dev='vda' bus='virtio'/> </disk>

这里 target dev 是 vda，说明客户机里的设备名是 /dev/vda。如果有多块磁盘，就是 vda、vdb、vdc 这样排下去。很多人在这一步不看设备名，直接在客户机里对 /dev/sda 操作，结果发现根本没这个设备，因为 virtio 磁盘通常以 vd 开头。

然后进客户机里看一眼分区和文件系统的现状：

lsblk df -hT

通过 lsblk 可以看到当前磁盘 vda 的总容量，以及它下面有哪几个分区。df -hT 则能看到每个分区的文件系统类型和使用率。这里要特别留意文件系统类型，因为 ext4 和 xfs 的扩容命令完全不一样。ext4 用 resize2fs，xfs 用 xfs_growfs，用错了命令会直接报错。

2.2 宿主机侧镜像扩容的两种方式

宿主机侧扩容镜像，最常见的是 qemu-img resize。假设要把 vm01.qcow2 从当前容量增加 20G，可以执行：

qemu-img resize /var/lib/libvirt/images/vm01.qcow2 +20G

注意这里用的是 +20G，意思是增加 20G。如果写成 20G（不带加号），那就是把镜像大小直接改成 20G，而不是增加，这一点特别容易踩坑。比如原本镜像大小是 50G，执行 qemu-img resize vm01.qcow2 20G，结果把镜像缩小成了 20G，数据全废。所以我的习惯是每次扩容都明确写加上“+”号，并且执行前先qemu-img info看一眼当前大小。

除了 qemu-img resize，还有一个更“偷懒”的方式，那就是直接修改虚拟机 XML 里的磁盘容量。不过我不推荐这种方式，原因是它绕过了 QEMU 对镜像文件的元数据校验，容易造成宿主机侧看到的镜像逻辑大小和实际文件系统不一致。反而是使用 qemu-img resize，它会同步修正 qcow2 镜像文件头里的 virtual size 字段，后续不管用 libvirt 还是 qemu 命令行管理这个镜像，信息都是一致的。

扩容完成后，可以执行：

qemu-img info /var/lib/libvirt/images/vm01.qcow2

看一下输出里的 virtual size 是否已经变成了新的大小。如果仍然是旧大小，说明命令没有生效，要检查是不是权限问题（比如镜像文件的属主是 qemu 用户，而你用 root 执行，一般没问题）或者磁盘路径写错了。

2.3 客户机侧刷新设备容量的机制

宿主机把镜像撑大了，客户机里的操作系统并不会立刻知道自己“换了大硬盘”，需要靠一些机制去刷新。在 Linux 客户机里，最简单的方式是：

echo 1 > /sys/class/block/vda/device/rescan

不过这条命令并不是在所有发行版上都有效，尤其是较新的内核，可能连 /sys/class/block/vda/device/rescan 这个文件都没有。更通用的做法是使用blockdev --rereadpt，但它的作用对象是整个磁盘，而且有些场景下会因为分区忙而失败。在 KVM 的 virtio-blk 驱动下，多数时候只要执行partprobe就能让内核重新读取分区表：

partprobe /dev/vda

如果 partprobe 没有输出错误，说明分区表已经刷新成功。你也可以用lsblk确认一下 vda 的总容量是否已经变大。这里有个很重要的点：lsblk显示的是内核当前感知到的块设备容量，如果宿主机扩容后 lsblk 显示的还是旧容量，说明客户机内核没有刷新成功。此时可以先试试：

blockdev --rereadpt /dev/vda

如果仍然失败，那可能需要重启虚拟机才能让内核重新识别，不过这种情况在 virtio-blk 驱动下很少见。我遇到过一次失败是因为虚拟机内跑了一个正在使用 vda1 分区的数据库进程，导致内核锁定了一部分块设备。此时我选择了在业务低谷短暂停掉数据库，再刷新分区表，成功后再把数据库启动起来，效果等同于零停机。

2.4 分区表类型决定扩展方式

客户机里的磁盘分区表有两种常见类型：MBR（旧式主引导记录）和 GPT（新型全局唯一标识分区表）。这两种分区表的扩展方式有细微差别。传统 MBR 分区表最多支持 2T 的磁盘容量，如果你想把磁盘扩展到超过 2T，那必须使用 GPT。另外，MBR 的主分区数量有限，扩展的时候如果分区不是最后一个分区，会比较麻烦。

检查分区表类型：

fdisk -l /dev/vda

输出会明确显示 Disk label type 是 dos（MBR）还是 gpt。如果当前分区表是 MBR，且磁盘需要扩展到 2T 以上，建议一步到位改为 GPT。但要注意，MBR 转 GPT 不是无痛操作，一般需要离线处理或者借助专门的工具，即便是在线转换也要求分区布局不能超出 GPT 的限制。如果只是普通扩容 10G、20G，保持原有分区表类型即可，不用折腾。

在扩展分区时，我强烈建议使用growpart工具，它专门用来在保留分区内容的前提下增加分区的大小。用法非常简单：

growpart /dev/vda 1

这个命令的意思是把 /dev/vda 的第 1 个分区扩展到整个磁盘尾部，前提是这个分区是磁盘上的最后一个分区。如果分区后面还有别的分区，比如第 1 个分区和第 2 个分区之间有空隙，或者第 1 个分区不是最后一个分区，growpart 会拒绝执行。所以一个合理的磁盘布局应该是：数据分区放在最后，这样扩展其他分区时不会受限制。如果你当前的分区方案不是这样，那就需要先备份数据，然后用 parted 调整分区边界，这个属于高风险操作，不建议在线执行。

其实还有一个简单的思路：如果客户机里的系统盘分区（比如 /dev/vda1）已经放到了磁盘末尾，那 growpart 自动就能搞定。如果系统盘分区不是最后一个，我一般建议你干脆不要把系统盘和数据盘混在一个磁盘上，更好的做法是把数据盘单独作为一个磁盘设备加给虚拟机，需要扩容时就扩展这块数据盘，系统盘保持不动，这样复杂度会低很多。

2.5 文件系统扩展的两种命令

当分区已经变大了，文件系统还停留在原来的大小。最后一步就是把文件系统填充到整个分区。这里要先确认文件系统类型，然后选择对应命令。

对于 ext4（包括 ext3 和 ext2）：

resize2fs /dev/vda1

如果文件系统挂载在根目录，而且当前系统正在使用它，resize2fs 也能在线完成扩展。它可以自动检测分区的新容量，然后把文件系统扩展到最大。如果想要指定大小，可以用resize2fs /dev/vda1 50G这种方式，但现实里很少用，一般直接不指定大小，让它扩满整个分区就行。

对于 xfs：

xfs_growfs /

注意，xfs 的命令不是直接给设备名，而是给挂载点。你可以使用xfs_growfs /或者xfs_growfs /data，它会自动计算挂载点对应的文件系统当前大小和底层分区大小，然后在线扩展。xfs 文件系统不支持缩小，只支持扩大，所以如果你把分区缩了，xfs 文件系统是没法跟着缩回去的，这也是为什么在规划磁盘容量时要留够余量。

如果是 btrfs，也有对应的 btrfs filesystem resize，但 btrfs 在 KVM 客户机里相对少见，这里不展开。总的原则是先确认文件系统类型，再选对应工具，不要想当然地用 resize2fs 去处理 xfs，那肯定会报错。

2.6 LVM 场景的特殊处理

如果客户机内部用了 LVM（逻辑卷管理）来管理磁盘，那扩充链路会额外多一层。LVM 的核心结构是：物理卷（PV）→ 卷组（VG）→ 逻辑卷（LV）→ 文件系统。扩容时，你需要依次扩展 PV、VG、LV 和文件系统。

假设虚拟机里有一块 /dev/vdb 被作为物理卷加入了卷组 vg_data，逻辑卷 lv_home 挂载在 /home。宿主机把 vdb 镜像扩大到 100G 后，在客户机里依次执行：

pvresize /dev/vdb lvextend -l +100%FREE /dev/vg_data/lv_home resize2fs /dev/vg_data/lv_home # 如果文件系统是 xfs，则改用 xfs_growfs /home

pvresize 的作用是让 LVM 感知到物理卷底下块设备的容量变化，它会自动更新 PV 的大小。lvextend -l +100%FREE 的意思是把卷组里所有剩余空间都分给这个逻辑卷，这里的 100%FREE 是百分比写法，比写具体容量要省心，尤其当你不确定卷组到底有多少可用空间时。

用 LVM 的好处是分区这层已经被 LVM 抽象掉了，你不需要关心磁盘上有几个分区，也不用去调整分区表。LVM 在线扩展非常稳定，是现代 Linux 系统中最推荐的磁盘管理方式。如果你新建虚拟机时就在客户机里装好了 LVM，那在线扩容基本上就是一条命令链的事，非常顺滑。

3. 实操过程与核心环节实现

3.1 准备一个测试虚拟机

为了把整个流程串联起来，我这边用一个模拟项目环境来做演示。宿主机是一台 Linux 服务器，安装了 libvirt 和 KVM，测试虚拟机名为 test-vm-01，客户机是某主流 Linux 发行版，磁盘是一个 20G 的 qcow2 镜像，分区和文件系统布局是：/dev/vda1 为 / 根分区，文件系统为 ext4。当前使用率已经达到了 90%，业务系统产生告警，需要把磁盘扩展到 50G。

先确认虚拟机和磁盘状态：

virsh list --all qemu-img info /var/lib/libvirt/images/test-vm-01.qcow2 lsblk --output NAME,SIZE,FSTYPE,MOUNTPOINTS

执行结果会显示 test-vm-01 处于 running 状态，qcow2 镜像 virtual size 为 20G，客户机里 /dev/vda 有 20G，vda1 使用率 90%。在动手之前，我习惯先做一次文件系统检查，确保文件系统是干净的状态：

fsck -f /dev/vda1

注意：fsck 不能在文件系统挂载的情况下执行，如果你要检查根分区，得先确保它没有被挂载，或者使用相应的只读检查模式。但在线扩容时，根分区一定处于挂载状态，所以这个 fsck 其实做不了。强行走 fsck 反而会有风险。更稳妥的替代方案是：检查一下 dmesg 里有没有磁盘 I/O 错误，或者用 dumpe2fs 查看文件系统状态是否 clean。如果文件系统有异常，先解决异常再扩容，别在坏的文件系统上做 resize，否则可能加重损坏。

3.2 宿主机侧扩容镜像

确认一切正常后，在宿主机上执行：

qemu-img resize /var/lib/libvirt/images/test-vm-01.qcow2 +30G

这里的 +30G 是从 20G 增加到 50G 的意思。紧接着检查镜像信息：

qemu-img info /var/lib/libvirt/images/test-vm-01.qcow2

输出里会看到：

virtual size: 50 GiB (53687091200 bytes) disk size: 3.1 GiB

注意 virtual size 变成了 50G，而 disk size 只有 3.1G，这正好说明 qcow2 是稀疏文件，扩容不等于立刻占用物理空间，后续客户机写多少数据才会占用多少实际空间。这个特性对存储池容量规划很重要：假设存储池剩余空间只有 30G，你给虚拟机扩了 30G 虚拟空间，但实际磁盘占用可能只有几百兆，逻辑上存储池不会有压力。不过一旦虚拟机开始大量写入，存储池空间就会快速消耗，一定要提前观察存储池余量。

3.3 客户机内核刷新容量

镜像扩容完成后，回到客户机（可以通过 virsh console 或者 SSH 登录）。先让内核重新读取磁盘容量：

partprobe /dev/vda

如果没有报错，再用 lsblk 确认：

lsblk

这时应该看到 vda 的 SIZE 已经变成了 50G，但 vda1 分区仍然是原来的 20G，这正是预期状态。如果你的系统不支持 partprobe，也可以执行：

echo 1 > /sys/block/vda/device/rescan

不过 virtio 驱动下一般 partprobe 就够了。如果 partprobe 报“无法读取分区表”之类的错误，先确认宿主机侧镜像扩容是否成功，再检查客户机里有没有进程锁定磁盘。实在不行，只能短暂停用相关服务后重试。

3.4 用 growpart 扩展分区

现在磁盘是 50G，但 vda1 分区还是 20G，需要把 vda1 扩展到整个磁盘。执行：

growpart /dev/vda 1

这里要注意 growpart 参数中间有个空格，是设备名和分区号的组合，不是 /dev/vda1 这种写法。执行成功后，输出大致是：

CHANGED: partition=1 start=2048 old: size=... end=... new: size=... end=...

如果不放心，可以用 parted 查看当前分区信息：

parted -l

也可以直接查看 /proc/partitions：

cat /proc/partitions

确认 vda1 的容量已经接近 50G。这里有个细节：growpart 需要目标分区的 start 位置不变，只是把 end 位置往后挪，所以分区内的数据完全不受影响，这也是在线扩容的核心优势之一。

3.5 扩展文件系统

分区变大后，最后一环是扩展文件系统。因为我们这个客户机的根分区是 ext4，所以执行：

resize2fs /dev/vda1

执行过程中会输出文件系统扩容的进度：

resized filesystem which is now 13,107,200 blocks long.

说明文件系统已经扩展到新分区大小。然后 df -h 验证：

df -hT

此时 / 分区的 Size 应该变成了 49G 左右（刨去文件系统自身开销），Use% 大幅下降。到这里，整个在线扩容就完成了。整个过程虚拟机没有关机，业务进程也没有重启，只是中间可能出现极短暂的 I/O 阻塞（因为 resize2fs 会临时冻结文件系统的 I/O），但通常只有几秒甚至更短，对大多数业务无感。

3.6 xfs 场景的实操补充

换个场景，如果客户机的根分区是 xfs，那扩展文件系统的命令就不同了。在 growpart /dev/vda 1 之后，执行：

xfs_growfs /

xfs_growfs 会读取挂载点的文件系统信息，然后自动扩展到对应分区的新容量。它的输出中会显示新旧数据块数量，你只要看到 old blocks 和 new blocks 不同，就说明扩展成功了。xfs 在线扩展很成熟，几乎不会出问题。

但 xfs 有个点需要格外注意：它不支持缩小。假设你哪天想把分区缩小，xfs 方案下你做不了，只能备份数据、重新格式化。所以一开始规划 xfs 分区时，一定要把未来增值空间留足。相比之下 ext4 既可以扩大也可以缩小（缩小是有条件的），灵活性更高。

3.7 使用 LVM 的实操路径

如果客户机里采用了 LVM，完整操作路径举例：

假设有一个逻辑卷 lv_app 挂载在 /data，当前 PV 是在 /dev/vdb 上。宿主机先执行：

qemu-img resize /var/lib/libvirt/images/vm2-appdisk.qcow2 +20G

然后在客户机里执行：

partprobe /dev/vdb pvresize /dev/vdb vgs lvextend -l +100%FREE /dev/vg_app/lv_app resize2fs /dev/vg_app/lv_app df -hT /data

如果文件系统是 xfs，最后一步改成：

xfs_growfs /data

这里要注意：lv_app 的逻辑卷是在 /dev 下的映射路径，不要搞混了。用 vgs 确认卷组名称，用 lvs 确认逻辑卷路径，仔细一点就不会错。

4. 常见问题与排查技巧实录

4.1 qemu-img resize 没有任何输出？

有时候执行 qemu-img resize 命令后，终端就静悄悄地结束了，没有成功提示。这种情况通常是命令执行成功了，因为 qemu-img 在成功时不会打印太多信息。判断是否成功的唯一可靠方式是执行 qemu-img info 查看 virtual size。另外，确保你没有因为权限问题而实际上写了别的镜像。我曾见过有人把路径写错，结果扩容到了一个临时文件上，真正使用的镜像一点没变。建议在扩容之前和之后都执行一次 qemu-img info，并对比 virtual size 字段。

4.2 宿主机扩容后，客户机 lsblk 显示的磁盘大小没变？

这个问题最常见的原因是客户机内核没有重新读取磁盘容量。第一步先试试 partprobe，如果失败，使用 blockdev --rereadpt。如果都不行，检查一下虚拟机是不是用了非 virtio 总线的磁盘，比如 IDE。IDE 总线在线的热刷新能力较差，通常需要重启。如果确实无法刷新，而且业务不允许重启，那这个场景下在线扩容就不适用了，只能选择在业务窗口内短暂重启。

还有一种情况是虚拟机的镜像文件被快照链分成多层，qemu-img resize 只改了最顶层的镜像文件，但底层镜像的容量没有同步。这种时候需要检查镜像信息：

qemu-img info --backing-chain /var/lib/libvirt/images/test-vm-01.qcow2

如果看到 backing file 的 virtual size 还是旧值，那你需要先把快照合并，或者对底层镜像也做 resize。实际操作中，快照链会显著增加在线扩容的复杂程度，所以我通常在扩容前会先去查看有没有活跃快照，如果有，先合并简化。

4.3 growpart 报错 “unexpected amount of free space”

这条报错的意思通常是分区表中有非预期空闲空间，或者分区的 end 位置已经被提前占用了。最常见的原因是分区后面还存在空隙，或者磁盘的物理扇区大小和逻辑扇区大小不一致。解决方法是先用 parted 查看磁盘的详细布局：

parted /dev/vda unit s print

认真看每个分区的起始和结束扇区。如果分区后面确实有自由空间，growpart 应该是可以识别的；但如果分区本身不是最后一个分区，growpart 就会拒绝。遇到这种布局，只能考虑新增一块磁盘来解决问题，或者接受停机，在离线模式下用 parted 重建分区表。

4.4 resize2fs 报错 “Filesystem is already N blocks long”

这个报错很常见，原因是文件系统已经达到分区大小，或者分区大小没有变化。比如你只扩容了镜像，但没有执行 growpart，那分区仍是旧的 20G，resize2fs 发现文件系统已经是 20G，就不再做任何操作，同时提示这个信息。所以出现了这条提示，说明前面某一步没做或者没生效，回到 lsblk 检查分区大小即可。

另一个可能的原因是分区大小是对的，但 resize2fs 版本较老，不支持某种特性。这种时候先用 e2fsck 检查文件系统，再进行 resize2fs。注意 e2fsck 要在卸载状态下执行，如果分区是根分区，无法卸载，那就用 e2fsck -n 做个只读检查，确保文件系统没有严重错误，再继续。

4.5 在线扩容过程中虚拟机卡死或 I/O 错误

这个比较少见，但一旦遇到就是大事。最常见的原因是宿主机存储后端在扩容过程中响应变慢，比如网络存储（NFS、Ceph RBD）出现抖动，导致客户机 I/O 超时。这时候不要慌，先观察一段时间，很多时候只是瞬时的延迟。如果客户机完全卡死，可以在宿主机上用virsh suspend让它挂起，等待存储恢复后再virsh resume。但正常情况下，qemu-img resize 只涉及元数据写入，不会触发大量数据移动，所以造成 I/O 卡死的概率极低。只要你的存储后端不是处于故障边缘，就不用过度担心。

4.6 在线扩完容，但数据空间并没有增加

这种情况大概率是文件系统类型判断错误。比如你用的是 xfs，结果执行了 resize2fs，resize2fs 会直接报错，不会损伤数据；但如果你用的是 ext4，执行了 xfs_growfs，也会报错。最直接的排查方式是用 blkid 查看设备上的文件系统：

blkid /dev/vda1

根据输出里的 TYPE= 字段选择正确的扩展命令即可。

4.7 扩容后系统重启失败

在线扩容后虚拟机一切正常，但重启后却无法启动，这种情况多数是分区表的问题。growpart 操作本身是安全的，但如果你在操作前没有备份分区表，而中途又出现了意外（比如宿主机断电、镜像文件损坏），那就可能导致分区表不一致。我的习惯是：在任何分区操作之前，先备份分区表到宿主机：

sfdisk -d /dev/vda > /root/vda.partition.bak

如果重启失败，可以用这个备份文件在救援模式下恢复分区表。当然，更保险的方案是在扩容前给客户机做一次虚拟机快照。不过在线扩容场景下，底层还是存在风险，所以对重要虚拟机，我一般会选择先创建一个外部快照，再执行扩容操作。这样万一出问题，可以快速回滚。

4.8 常见问题速查表

4.9 一个容易被忽略的细节：分区对齐

无论是 qemu-img resize 还是 growpart，最终扩展出来的空间，起始扇区是不变的，所以不会出现对齐问题。但如果你在初始规划时分区起始位置就没有对齐（比如起始扇区是 63 或者 1），那后续扩容虽然能用，但性能会大打折扣。现代 Linux 的 parted 和 fdisk 默认已经能自动对齐，但如果你用的是非常老的初始化工具，最好检查一下 /sys/class/block/vda1/start 或者 parted 输出中的 start 值，通常应该是 2048 的倍数。如果没对齐，在线扩容解决不了性能问题，只能新建对齐好的分区并且迁移数据，这已经超出现有进程的范畴了。

5. 写在最后的实用心得

做了这么多年虚拟化运维，我对磁盘扩容最大的体会就是：一定要小步慢走，每一步都验证。不要一口气把镜像、分区、文件系统全扩完再去检查，那样一旦出错，根本不知道是哪个环节出了问题。正确的方式是每执行一步，都立刻用 lsblk、df -h 去确认结果，确认无误后再进行下一步。

另外，在线扩容虽然方便，但绝不是事前不做备份的理由。数据安全永远是第一位，尤其在处理数据库、状态文件这类关键数据时，最好先创建虚拟机快照，再开始操作。多数时候快照占了空间但没被用到，可一旦出了问题，你会庆幸当初留了后路。

最后再分享一个很多人容易忽略的小技巧：扩容完成后，最好检查一下客户机里的定时任务、日志轮转配置，因为磁盘空间变大了，原先按百分比触发的清理策略可能就不会及时触发，如果后续磁盘又被写满，反而让你误以为扩容失败了。其实扩完容，适当调整一下监控阈值和清理频率，整个系统才会更稳定。这套在线扩容的方法我一直在用，实测下来非常稳，只要按链路来，不跳步，基本不会翻车。