qemu-img resize仅更新qcow2镜像元数据，guest需手动扩展分区和文件系统才能真正扩容；用qemu-img resize disk.qcow2 +20G或50G调整virtual size，再在guest中partprobe、fdisk/pvresize、resize2fs/xfs_growfs依次操作。
qemu-img resize 可以在线扩大 qcow2 虚拟空间，但仅改镜像元数据，guest 里看不到新空间 —— 必须后续手动扩展分区和文件系统才算真正扩容成功。
qemu-img resize 命令怎么用才不翻车
宿主机上执行 qemu-img resize 是第一步，也是唯一能在虚拟机运行时安全操作的环节。关键点在于理解两个参数形式的区别：
-
qemu-img resize disk.qcow2 50G：设为绝对大小（目标 virtual size），适合明确知道最终容量的场景 -
qemu-img resize disk.qcow2 +20G：在当前 virtual size 上增量增加，更直观、不易算错 - 别用
-shrink参数在线缩容 —— 即使加了--force也极可能损坏数据，必须关机后谨慎操作 - 执行后立刻用
qemu-img info disk.qcow2 | grep "virtual size"验证，确保输出值已更新（如从20G变成50G）
为什么 df -h 看不到新空间？因为 guest 还不知道磁盘变大了
扩容后启动虚拟机，lsblk 或 fdisk -l /dev/vda 会发现设备大小（如 /dev/vda）已变成 50G，但里面分区（如 /dev/vda1 或 /dev/vda3）仍卡在旧大小 —— 这是常见误判源头。
- Linux guest 默认不会自动重读分区表，需手动触发：
partprobe /dev/vda（部分内核版本不支持，可重启或用echo 1 > /sys/block/vda/device/rescan） - 如果分区表是 MBR 类型，且最后一个分区不是扩展分区，
fdisk无法直接扩展，得先删再建（起始扇区必须严格保持原值，否则数据丢失） - LVM 场景下，
/dev/vda2可能是 PV，此时要先pvresize /dev/vda2，再lvextend，最后才是文件系统扩容
ext4 和 xfs 文件系统扩容命令不能混用
分区扩展完只是“画好地界”，文件系统还得自己去占满这块地。不同格式工具完全不同：
- ext4（含 ext3/ext2）：
e2fsck -f /dev/vda1（强制检查）→resize2fs /dev/vda1（在线执行，无需 umount） - xfs：
xfs_growfs /（挂载点路径，不是设备名！）—— 必须已挂载，且只接受挂载点，传/dev/vda1直接报错invalid argument - 若
resize2fs报The filesystem is already <size> blocks long. Nothing to do!</size>，说明分区根本没扩，回退查fdisk -l /dev/vda输出里的 End 扇区是否变大
最容易被忽略的是：qcow2 镜像扩容后，guest 内核看到的块设备容量变化需要底层驱动配合。某些老内核（如 3.10 之前）对热扩容响应迟钝，partprobe 失效时，最稳的方式仍是冷重启 guest —— 别省这几十秒。
