贵萌兄好多年前第一次给KVM虚拟机做磁盘扩容的时候，我脑子里的想法特别简单：宿主机上把镜像文件变大，重启虚拟机进去应该就自动变大了吧。结果当然是翻车了——虚拟机里 lsblk 看了半天，磁盘大小纹丝不动，当时还怀疑是不是镜像没扩成功。后来才慢慢搞明白，KVM磁盘扩容这件事，严格来说是“宿主机改镜像 + 虚拟机内部分区文件系统调整”两个阶段，缺一步都不行。
这篇文章我打算把这套流程从原理到实操完整捋一遍，包括 raw 和 qcow2 两种镜像格式的区别、扩容前要做哪些检查和备份、宿主机侧的命令怎么敲、虚拟机内部 MBR 分区、LVM、xfs 这些常见场景分别怎么处理，以及我这些年实际踩过的坑。适合刚接触 KVM 的运维新手，也适合已经会基本操作但没系统整理过这套流程的朋友，照着文档一步步来基本能避掉九成的雷。
1. 底层认知先补齐：raw 与 qcow2 格式决定扩容姿势
1.1 两种镜像格式的本质差异
KVM 默认的磁盘镜像格式主要是 raw 和 qcow2 两种。这两个格式不是随便选的，直接决定了你后面扩容要用什么手段。
raw 格式最简单，它就是一个线性的块设备文件，文件里是什么字节，虚拟机的磁盘里就是什么内容，没有任何中间层。所以 raw 格式性能损耗最小，IO 路径最短，直来直去。但缺点也明显，创建多大就占多大空间，不支持快照、压缩这些高级特性。qcow2 则复杂一些，它是 QEMU 的 Copy-On-Write 格式，文件内部有元数据表管理块分配，支持稀疏文件、快照、AES 加密、zlib 压缩。qcow2 创建时看着很小，实际用多少才占多少，对宿主机磁盘空间比较友好。
这两种格式扩容的核心区别在于：raw 格式的镜像，你可以用 qemu-img 命令直接扩，也可以用 truncate 或者 dd 磁盘追加的方式扩；qcow2 格式则强烈建议统一用 qemu-img resize，因为 qcow2 内部有元数据，直接 truncate 会把文件搞坏。我见过有人拿 truncate 硬扩 qcow2，结果虚拟机直接起不来，镜像元数据全乱了。
1.2 扩容前先确认镜像格式
判断当前虚拟机用的是哪种格式，最简单的办法就是看虚拟机配置文件和宿主机上的镜像文件。先看域定义文件：
bash复制virsh dumpxml vm-name | grep -A 2 'disk'
重点看 source file 路径和 driver type 字段。driver type 如果写着 qcow2，那这就是 qcow2 格式；如果写着 raw，那就是 raw 格式。
然后到宿主机上直接用 qemu-img info 确认：
bash复制qemu-img info /var/lib/libvirt/images/vm-name.qcow2
输出里有 image format、virtual size、disk size 这几项。virtual size 是虚拟机看到的逻辑磁盘大小，disk size 是实际占用宿主机空间的大小。如果 virtual size 和 disk size 差很多，说明这是个稀疏文件或者 qcow2 格式，扩容时更要小心别把稀疏特性搞丢。
注意：扩容前一定要把虚拟机关机或者至少做快照备份，这一点后面单说，但这里先立个规矩——任何对镜像文件本身的写操作，都别在虚拟机运行状态下进行，除非你用的是 libvirt 的块设备在线扩容方案（那个后面也会提）。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 扩容前的方案选型：加新盘还是扩原盘
2.1 两种扩容思路的适用场景
KVM 磁盘扩容实际上有两条路：一条是给虚拟机加一块全新的虚拟磁盘，把数据迁移过去或者当作新挂载点使用；另一条是直接扩大现有磁盘镜像，然后在虚拟机内部把分区和文件系统撑大。
加新盘的好处是操作风险低，不需要动原有分区表，在虚拟机里 fdisk 新建分区、格式化、挂载就行，整个过程对已有数据几乎零风险。缺点是如果你的业务数据原本都在一个挂载点上（比如根分区），你得手动迁移数据、改 fstab，甚至重新规划目录结构，麻烦事也不少。扩原盘的好处是分区结构不用变，根分区可以直接变大，业务无感，数据库、日志这些路径都不用改。但代价是操作步骤多，尤其涉及到根分区在线扩容的时候，稍有疏忽就可能分区表损坏。
我的习惯是：如果只是根分区空间不够用，优先扩原盘；如果是想把数据目录单独拆出来，优先加新盘。这两个思路不冲突，很多生产环境都是混合用的。
2.2 扩容前的三件事：备份、快照、空间检查
先说备份。扩容操作本质上是一次“写操作”，即便是经验丰富的人也有可能敲错命令，把分区表搞崩。所以扩容前我强烈建议做两件事：第一，对虚拟机的数据做逻辑备份（比如数据库导出、关键文件打包）；第二，在 KVM 层面给虚拟机打一个快照。如果是 qcow2 格式，可以用 virsh 直接打快照：
bash复制virsh snapshot-create-as vm-name pre-disk-expand --disk-only
这个命令会给当前磁盘状态生成一个内部快照，万一扩容失败，可以直接回滚。但注意，disk-only 快照会生成一个新的 qcow2 覆盖文件，原有镜像变成了快照的 backing file，后续操作路径会变复杂。所以更稳妥的做法是：先把虚拟机关机，然后直接复制一份镜像文件到备份目录，这是最原始也最可靠的办法。
bash复制cp -a /var/lib/libvirt/images/vm-name.qcow2 /backup/vm-name.qcow2.bak
如果是 raw 格式，复制起来更简单，dd 或者 cp 都行，raw 没有内部元数据，拷贝完就是完整副本。
第三件事是检查宿主机剩余磁盘空间。很多人扩容失败是因为宿主机磁盘快满了。镜像扩容后，虚拟机的 virtual size 会变大，但实际占用的空间会随着虚拟机内部写入逐渐增长。如果你给虚拟机扩了 50G，宿主机可用空间却只剩 20G，短期内可能没事，等虚拟机写入数据之后宿主机磁盘就会被写满，连带着其他虚拟机一起遭殃。
bash复制df -h
这一步检查一下宿主机根分区或者镜像所在挂载点的剩余空间，建议至少留出 1.2 倍的扩容空间余量。曾经有一次我忽略了这一点，扩容完 qcow2 之后虚拟机正常，但过了两天宿主机根分区直接 100%，所有虚拟机 IO 全部阻塞，那次经历让我至今心有余悸。
3. 宿主机侧操作：让虚拟磁盘“变胖”的正确姿势
3.1 qemu-img resize 命令详解
确认好格式、做完备份、检查完空间之后，就可以在宿主机侧扩容镜像文件了。核心命令就是 qemu-img resize。
bash复制qemu-img resize /var/lib/libvirt/images/vm-name.qcow2 +20G
这个命令的意思是把镜像的 virtual size 增加 20G。注意加号的作用是“增加多少”，如果你写的是“20G”，那意思是把磁盘直接设置成 20G，这在某些情况下会导致缩小操作，非常危险。缩容 KVM 镜像这件事远比扩容复杂，qemu-img 官方也不建议直接用 resize 做缩容，所以我在生产环境里从来不用不带加号的写法。
扩容完成后，用 qemu-img info 再看一次：
bash复制qemu-img info /var/lib/libvirt/images/vm-name.qcow2
确认 virtual size 已经变成扩容后的大小，disk size 不变（因为刚扩完还没写入数据，文件实际占用空间不会立刻变大）。
3.2 raw 格式的扩容特殊处理
raw 格式除了 qemu-img resize，还有一个常用办法是 truncate：
bash复制truncate -s 50G /var/lib/libvirt/images/vm-name.raw
这条命令把 raw 文件直接截断/扩展到 50G。为什么 raw 可以这么干？因为 raw 格式没有内部元数据，文件大小就是虚拟磁盘大小，truncate 把文件尾部补零，虚拟机看到的就是一块更大的空白区域。这个操作很快，几秒钟就完成，比 qemu-img resize 还快。但我要提醒一句：truncate 只能用于 raw，千万别对 qcow2 用。qcow2 文件的大小并不等于磁盘大小，直接用 truncate 扩出来的是“文件空洞”，qcow2 的 L1/L2 元数据表根本不知道这事，虚拟机识别不了。
另外 raw 格式也可以用 dd 追加的方式：
bash复制dd if=/dev/zero of=/var/lib/libvirt/images/vm-name.raw bs=1M count=20480 oflag=append conv=notrunc
这个方式本质上和 truncate 一样，只是多了一个写零的过程，如果文件不是稀疏文件，dd 追加会在文件尾部真实写入 20G 零数据，比较慢。日常我一般选用 truncate，因为大多数 raw 镜像本身就是稀疏文件，秒完成，还不占额外空间。
3.3 在线扩容与离线扩容的选择
前面说的都是离线扩容，也就是先把虚拟机关机再操作。但有些生产环境停机窗口很短，这时候可以考虑 libvirt 的在线扩容能力。
qcow2 格式的在线扩容其实也走 qemu-img，但需要先通过 blockresize 告诉运行的 QEMU 进程重新读取磁盘大小。libvirt 提供了 virsh blockresize 命令：
bash复制virsh blockresize vm-name vda 50G
这里的 vda 是虚拟机的目标磁盘设备名，50G 是扩容后的大小。执行前还是要先 qemu-img resize 把底层镜像文件变大，然后 blockresize 让运行中的虚拟机感知到新大小。在线扩容的好处是不需要停机，坏处是虚拟机内部的文件系统扩容部分仍然有风险，尤其是根分区的文件系统，在线 resize 失败的话可能直接导致根文件系统损坏。
我的习惯是：能停机就停机，不能停机再考虑 blockresize，但无论如何虚拟机内部的步骤都要特别小心。在线扩容更适合给数据盘扩，不太建议在生产环境给正在运行的系统盘做在线扩容。
4. 虚拟机内部操作：分区和文件系统才是真正的重头戏
4.1 虚拟机内查看磁盘现状
宿主机侧镜像扩大只是第一步，虚拟机内部的操作才是大多数人翻车的重灾区。启动虚拟机后，先用 lsblk 看一下磁盘情况：
bash复制lsblk
你会看到磁盘设备的大小已经变大了，比如原来是 20G，现在是 40G，但分区还是原来的大小，分区的可用空间没变。这一步确认后，再确定分区表类型：
bash复制fdisk -l /dev/vda
看输出里的 Disk label type，如果显示 dos，那就是 MBR 分区表；如果显示 gpt，那就是 GPT 分区表。这两种分区表的扩容方式不太一样，MBR 的老式分区扩容有 2T 上限问题，GPT 就没这个限制，而且 GPT 通常还会带一个备份分区表，扩容时要留意。
4.2 场景一：MBR 分区 + ext4/xfs 的非 LVM 结构
这是最简单的场景。假设虚拟机只有一个主分区 /dev/vda1 挂载在根目录上，文件系统是 ext4。首先需要让分区变大。
最安全的办法是用 growpart 工具：
bash复制yum install -y cloud-utils-growpart
# 或者
apt install -y cloud-utils-growpart
然后执行：
bash复制growpart /dev/vda 1
这条命令的作用是调整 /dev/vda 这个磁盘上的第 1 个分区，让它扩展到磁盘末尾。growpart 的原理其实就是在分区表层面把分区的结束扇区改大，不删除分区、不重建分区表，所以对数据非常安全。它的前提是分区后面必须有未分配空间，而我们在宿主机侧扩的磁盘空间正好满足这个条件。
如果系统里没有 growpart，也可以手动用 fdisk 操作，但不建议新手这么干，因为 fdisk 的经典做法是删除分区再重建，一旦起始扇区写错，数据就没了。所以我强烈推荐 growpart。
分区扩大后，再扩展文件系统。ext4 用 resize2fs：
bash复制resize2fs /dev/vda1
xfs 用 xfs_growfs：
bash复制xfs_growfs /
注意 xfs 的扩展命令参数是挂载点而不是设备名，这和 resize2fs 有点区别。resize2fs 可以离线也可以在线，xfs_growfs 只能在挂载状态下执行，这点很多人经常搞混。
4.3 场景二：LVM 结构的扩容
CentOS/RHEL 系列的默认安装很多都是 LVM 结构，这种结构多了一层逻辑卷管理层，扩容步骤也要多一步。
先看结构，典型布局是：/dev/vda2 是整个 PV，VG 叫 centos 或 cl，LV 有 root 和 swap。扩容时同样先用 growpart 把分区变大：
bash复制growpart /dev/vda 2
然后让 PV 感知到新空间：
bash复制pvresize /dev/vda2
执行完可以用 pvs 看到 PV 的 size 变大了，或者用 pvdisplay 查看 Free PE 的数量。接下来把剩余空间全部给 root LV：
bash复制lvextend -l +100%FREE /dev/mapper/centos-root
这里说一下为什么用 -l +100%FREE，因为 LVM 支持按百分比分配空间，100%FREE 的意思是把 VG 里所有空闲的 PE 全部划给当前 LV。你也可以用 -L +20G 指定增加 20G，但这样容易留下零头空间，下次还得再操作，不如一次性全给。
LV 扩完之后，最后一步仍然是扩文件系统：
bash复制# ext4
resize2fs /dev/mapper/centos-root
# xfs
xfs_growfs /
LVM 的好处在于扩展文件系统这个动作变得非常灵活，PV 空间不够就扩 PV，VG 空间不够就加 PV，整个体系都是模块化的。但也正因为多了一层，排错链路变长，经常有人分区扩了、PV 扩了、LV 也扩了，却忘了最后一步文件系统，导致 df -h 看还是老样子。
4.4 场景三：有分区表 GPT 和多个分区的处理
如果虚拟机里是 GPT 分区表，growpart 同样适用，但要注意 GPT 有备份分区表的概念。growpart 在调整最后一个分区时会自动更新备份 GPT 头，一般不需要人工处理。如果你遇到扩展后系统重启报“GPT 分区表已损坏”之类的告警，可以用 parted 的修复命令重新写一份备份分区表：
bash复制parted /dev/vda
(parted) print
(parted) rescue
不过大多数情况下 growpart 都能处理好，这个告警场景比较少见。多分区的情况下，growpart 只能扩最后一个分区，如果你想把中间的一个分区变大，growpart 帮不上忙，只能手动调整分区表，这种操作风险极高，一般建议用加新盘的方式绕过。
4.5 场景四：Windows 虚拟机的磁盘扩容
KVM 上跑 Windows 虚拟机的情况也不少，Windows 的扩容流程和 Linux 不太一样，但宿主机侧的操作是一样的。Windows 虚拟机的磁盘镜像扩容完成后，进系统右键“此电脑”->“管理”->“磁盘管理”，你会看到磁盘显示未分配空间，右键对应的分区选“扩展卷”，一路下一步就完成了。
如果扩展卷是灰色的，通常是因为分区后面有恢复分区或者 EFI 分区挡着，Windows 自带的磁盘管理不允许跨分区扩展。这时候有几种解决办法：一是用第三方工具如 DiskGenius、分区助手；二是先把中间的恢复分区删掉再扩展，但删恢复分区有风险；三是使用 Diskpart 命令行方式。我自己遇到这个问题的频率不低，特别是 OEM 镜像装出来的 Windows，扩展卷基本都会被挡住。这种场景下我一般推荐第三方工具，操作直观，失败率也低。所以 Windows 虚拟机扩容的重点其实不在 KVM 侧，而在 Windows 系统内部的磁盘管理逻辑，这个提前了解能少走很多弯路。
5. 常见问题与排查技巧实录
5.1 扩容后虚拟机功能正常但 lsblk 看不到新空间
这是最高的一个坑。宿主机镜像已经变大了，虚拟机里 lsblk 磁盘设备也显示大了，但分区还是老样子。很多人这时候怀疑扩容没成功，其实不是——这只是因为分区表还没更新。解决方式就是执行 growpart 扩分区，再扩文件系统。遇到这个问题先别慌，按顺序检查：qemu-img info 确认镜像大小 -> lsblk 确认磁盘设备大小 -> growpart 确认分区大小 -> 扩容文件系统。一步步排查就能定位到具体卡在哪一层。
5.2 数据盘扩容后新空间消失了
这个坑常见于多盘虚拟机。有时候你扩容的是 /dev/vdb，但虚拟机里 lsblk 发现 /dev/vdc 变大了，这是因为虚拟机里磁盘设备名和宿主机上的 target 不一定一一对应，尤其是热插拔过设备的虚拟机，设备名可能会漂移。排查方法是用 blkid 或 /dev/disk/by-path 下的软链接来确认设备身份，不要只看设备名。我自己有一次就是给第二块盘扩的容，结果进虚拟机把第三块盘的分区给改了，还好操作前有备份，否则后果不堪设想。
5.3 resize2fs 报错说 magic number 不对
这个报错通常发生在线扩容 xfs 文件系统时用了 resize2fs 命令。xfs 扩容必须用 xfs_growfs，这和 ext4 的 resize2fs 不是一回事。如果你执行 resize2fs /dev/mapper/centos-root 却收到 bad magic number 的报错，大概率是文件系统本身就是 xfs，命令用错了。解决办法很简单，换成 xfs_growfs / 就好。对新手来说，不确定文件系统类型时可以用 df -T 先查一下。
5.4 fdisk 手动扩分区导致分区表灾难
虽然我推荐 growpart，但总有人习惯用 fdisk 手动操作。fdisk 扩容分区的经典流程是删除分区再重建，起始扇区要完全一致，否则分区里的数据就全废了。一旦不小心把起始扇区写错，千万不要保存退出，直接按 q 退出，然后重新进 fdisk 用打印功能确认原来的起始扇区。如果真的保存了，也不要再分区上做任何写操作，立即求助数据恢复工具，或者从备份恢复。这里我想多说一句：fdisk 手动操作分区表，本质上是在改硬盘的“目录索引”，任何一个字节的错误都可能让整个分区的数据不可见，所以能不手工就不手工。
5.5 快照嵌套导致的镜像异常
如果之前给虚拟机做过快照，运行中的虚拟机实际上在用快照生成的覆盖文件，而不是你看到的原镜像。这时候直接对原镜像做 qemu-img resize，扩的根本不是虚拟机当前使用的文件，虚拟机启动后可能还是老大小。排查方式是用 virsh domblklist vm-name 查看实际使用的镜像路径，确认这个路径是预期中的那个文件，再做扩容。如果发现有嵌套快照，最好先把快照合并完再扩容，否则扩容操作可能作用在错误的文件层上。
6. 一份可以直接抄的扩容检查清单
最后分享一份我每次扩容都会过一遍的检查清单，每一步对应一个实际问题，照着来基本能一次成功：
- 虚拟机关机，确认没有重要任务在跑。
- 备份镜像文件到独立目录，至少保留到扩容验证通过。
- 检查宿主机剩余空间，预留至少扩容量的 1.2 倍。
- qemu-img info 确认镜像格式和当前大小。
- qemu-img resize +20G 或 truncate 扩 raw 文件，再 qemu-img info 复核。
- 启动虚拟机，登录系统。
- lsblk 确认磁盘设备自身大小已变化。
- df -T 确认根分区或目标分区的文件系统类型。
- growpart 扩分区，pvresize 处理 LVM（如果是 LVM 结构）。
- lvextend 把空间分配给目标 LV，再按文件系统类型执行 resize2fs 或 xfs_growfs。
- df -h 确认最终挂载点容量符合预期。
- 验证业务功能正常，再删掉备份或快照。
这套流程看起来步骤多，其实熟练之后十分钟内就能完成一次安全扩容。我个人在实际操作中最大的体会是：扩容本身不复杂，复杂的是你对每一步操作可能带来的后果有没有清醒的认识。备份永远不嫌多，命令永远先复核，尤其是碰到生产环境、根分区、LVM 组合拳的时候，多花五分钟检查，比出问题后折腾一晚上要划算得多。