使用qemu-img create -b 创建差分盘时必须指定存在且只读的后端镜像绝对路径，-f 仅指定新镜像格式，创建后须立即用 qemu-img info --backing-chain 验证链完整性。
qemu-img create -b 创建差分盘时必须指定后端镜像路径
直接用 qemu-img create -f qcow2 -b 创建差异镜像，本质就是启用写时复制（COW）——新镜像不存原始数据，只记录变更。关键前提是：后端镜像（backing file）必须存在、可读、且**不能被其他进程写入**。
常见错误现象：qemu-img info 显示 backing file: (null) 或启动虚拟机时报 Could not open backing file，基本是路径写错、权限不足，或后端镜像被 qemu 进程独占锁定（比如正在运行中）。
- 后端镜像建议设为只读：
chmod 444 base.qcow2，避免误写 - 路径必须是绝对路径或相对于当前工作目录的准确路径；相对路径在虚拟机启动时容易失效
- 不要对正在运行的虚拟机磁盘做
-b操作——哪怕只是qemu-img info，也可能触发元数据刷新导致冲突
为什么不用 -f qcow2 两次？格式参数只需写一次
qemu-img create 的 -f 指定的是**新建镜像的格式**，不是后端格式。后端镜像的格式由其自身决定，qemu-img 会自动识别并写入到新镜像头里（通过 backing_fmt 字段）。重复写 -f qcow2 不报错但冗余，还可能掩盖真实问题。
示例命令正确写法：
qemu-img create -f qcow2 -b /var/lib/libvirt/images/ubuntu-base.qcow2 ubuntu-dev.qcow2
错误写法（多此一举且易混淆）：
qemu-img create -f qcow2 -b ubuntu-base.qcow2 -f qcow2 ubuntu-dev.qcow2
如果后端是 raw，命令一样成立，qemu-img 会自动把 backing_fmt=raw 写进新镜像头——你不需要、也不应该手动指定。
创建后立刻验证 backing chain 是否完整
差分盘一旦损坏或断链，就无法启动。创建完必须立刻用 qemu-img info --backing-chain 检查整条依赖链是否可访问、格式是否匹配。
输出应类似：
image: ubuntu-dev.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /var/lib/libvirt/images/ubuntu-base.qcow2 backing file format: qcow2 ... image: /var/lib/libvirt/images/ubuntu-base.qcow2 file format: qcow2 virtual size: 20G disk size: 1.2G ...
- 若中间某一级显示
backing file: (null)，说明该层没正确继承或已被破坏 - 若某级提示
Could not open 'xxx': No such file or directory，就是路径或权限问题 - 注意
virtual size必须一致——差分盘不能比后端更大，否则启动时会报Image is corrupted
预分配策略（preallocation）对 COW 镜像几乎无意义
COW 差分盘的核心价值在于“极小初始体积 + 按需增长”。无论你加不加 -o preallocation=metadata 或 full，它都只记录变化块，不会预占后端镜像的空间。
唯一影响是元数据初始化速度和首次写入延迟：
-
preallocation=off（默认）：最快创建，首次写入略慢（要动态分配簇） -
preallocation=metadata：提前分配元数据区，首次写入更快，文件仍极小 -
preallocation=full：强制分配全部 20G 空间并置零——完全违背 COW 设计初衷，纯属浪费 I/O 和磁盘
除非你明确需要规避首次写入抖动（比如自动化测试环境），否则一律用默认 off。别被“预分配听起来更稳”误导——COW 的稳定性来自链路完整性，不是磁盘碎片控制。
差分盘最脆弱的环节永远是后端镜像的可用性。哪怕前端只有 192KB，只要后端文件被删、移动或 chmod 改错，整个链就立即失效。操作前备份后端，操作后立刻 qemu-img info --backing-chain，比任何预分配设置都重要。
