徐小疼搞虚拟化、做云平台运维的朋友，应该都绕不开 qemu-img 这个命令行工具。它是 QEMU/KVM 生态里最基础的磁盘镜像管理工具，创建虚拟机磁盘、做格式转换、查镜像信息、做快照、扩容缩容，全靠它。很多刚接触虚拟化的朋友容易忽视它的强大之处——以为就是"做个镜像文件"而已，实际上，不管是本地跑 KVM 还是管理一套私有云，qemu-img 都是离不了的核心操作。
我先说两个实际场景。第一个，从 OpenStack 或 OpenNebula 导出的镜像通常是 raw 或 qcow2 格式，但你在本地 VMware Workstation 里想直接用，就得转成 vmdk；反过来，你在公有云或虚拟机里做了一个调优后的 qcow2 镜像，想转到其他虚拟化平台，也离不开它。第二个场景，你手上有一批存量虚拟机，物理磁盘空间快满了，需要扩容系统盘，但分区装修不熟悉，直接改 qcow2 文件的大小又怕数据损坏，用 qemu-img resize 就能安全完成。这里面的门道，不是敲一条命令那么简单。
这篇手册我整理了 7 个专题，从格式选型、创建转换、镜像诊断到关联镜像链的 rebase/commit，再到一整套可落地的综合演练，全程配有详细案例和参数解释。我还会把平时踩过的坑、容易忽略的细节一并讲清楚。适合刚入门的同学建立完整认知，也适合有一定经验的运维参考排查问题的思路。
1. 镜像格式选型：理解 qcow2 与 raw 的区别，才能用对 qemu-img
用 qemu-img 之前，先要搞明白你在跟什么样的文件打交道。虚拟化里的"磁盘镜像"本质上是一个文件，但它模拟的是一块物理硬盘的二进制数据。qemu-img 支持多种格式：raw、qcow2、qed、vmdk、vdi、vhdx、vpc 等。最核心的两类就是 raw 和 qcow2。
1.1 raw 格式：简单直接，但空间管理靠稀疏
raw 格式的镜像可以理解为"物理磁盘的逐字节映射"，qemu-img 创建的 raw 文件，内容和一块空白硬盘的二进制数据是一一对应的。它的优势很明显：性能损耗极低，读写路径最直接；结构简单，几乎任何虚拟化平台都能识别。缺点也突出：如果分配了 100G 的 raw 文件，即使虚拟机里只用了 5G，它也会在宿主机上"假装"占 100G 的磁盘空间（实际占用的物理空间取决于文件系统的稀疏文件支持，比如 ext4 的延迟分配，但很多操作会破坏这种稀疏性）。
bash复制# 创建一个 100G 的 raw 镜像，注意观察 ls -lh 与 du -sh 的区别
qemu-img create -f raw disk.img 100G
ls -lh disk.img # 看到 100G
du -sh disk.img # 实际占用可能只有几M
这里就是我们常说的"稀疏文件"。ls -lh 看到的是"虚拟大小"，du -sh 看到的是"实际占用磁盘量"。很多新手搞不清这两个数字，导致宿主机磁盘规划出错。
1.2 qcow2 格式：写时分配与快照的基石
qcow2 是 QEMU 自创的一种镜像格式，全称是 QEMU Copy-On-Write version 2。它的核心价值有几点：
- 写时分配：创建 100G 的 qcow2 镜像，文件初始大小可能只有不到 200K，虚拟机里每写入一个扇区，镜像文件才按需增长。
- 快照支持：qcow2 天然支持内部快照，可以记录多个"历史时间点"。
- 压缩与加密：支持 zlib 压缩存储，也支持 AES 加密（虽然加密性能一般，但某些合规场景用得上）。
- 后代链：qcow2 可以基于另一个 qcow2 做差量盘，形成 backing chain，后文详细讲。
两者如何选？我个人的原则是：
| 场景 | 推荐格式 | 原因 |
|---|---|---|
| 本地单机跑 KVM，追求极致 IO | raw | 少一层格式转换开销 |
| 做虚拟机模板、批量克隆 | qcow2 | 省空间，支持差量盘，方便做快照 |
| 需要 VMWare 兼容 | vmdk | 跨平台格式，qemu-img 可转 |
| Windows 平台 Hyper-V 使用 | vhdx | qemu-img 支持转换，呵 |
| 冷数据备份归档 | qcow2 加压缩 | 转换时带 -c 参数压缩 |
提示：虽然 qcow2 性能差距在新版本 QEMU 中已大幅缩小，但对延迟极其敏感的数据库类负载，raw 依然有优势。中庸方案：模板用 qcow2，运行盘用 raw，取决于你是否需要频繁快照。
1.3 创建第一个镜像：实操 create 命令
qemu-img create 是我们最常打交道的子命令，参数不多，但有几个细节值得拆开讲。
bash复制qemu-img create -f qcow2 ubuntu.qcow2 50G
-f：指定格式，不指定时默认 raw。- 后面的路径是镜像文件名，最后一个是"磁盘虚拟大小"。
创建 qcow2 时还可以指定 -o 选项，比如 cluster_size、preallocation 等。默认的簇大小是 64K，这个值决定了 qcow2 内部数据块的管理粒度。如果你明确知道虚拟机里会存放大量碎小的文件（比如有些业务日志特别零碎），可以选择 16K 或 32K 的簇；如果是存放数据库库文件这种大块连续写入，可以用 128K 甚至 256K。不过要提醒一句，创建之后 cluster_size 就固定了，后期没法动态修改。
bash复制# 创建 20G 的 qcow2 镜像，簇大小 128K，并做 full preallocation，适合对磁盘空间稳定要求高的场景
qemu-img create -f qcow2 -o cluster_size=128K,preallocation=full data.qcow2 20G
preallocation 有三个常见值：off（默认，最省空间）、metadata（预分配元数据区域，部分优化）、full（全部分配，性能最好）。全分配模式创建大镜像会耗时较久，比如 100G 可能等上几分钟，但它能减少运行时按需分配带来的性能毛刺，适合对延迟敏感且磁盘空间充足的场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 镜像转换与信息查看：convert 和 info 的高频用法
转格式是 qemu-img 的"重头戏"，虚拟化平台间迁移、镜像分发、制作模板时都离不开。格式转换的核心命令就是 qemu-img convert。
2.1 convert 命令详解：从 raw 转 qcow2 完整案例
假设我有一块裸盘做了系统，导出为 raw 格式，现在想转成一个压缩的 qcow2 模板，命令如下：
bash复制qemu-img convert -p -f raw -O qcow2 -c disk.raw disk.qcow2
各参数解释：
-p：显示进度条，转换大文件时非常重要，否则你会以为进程卡死了。-f：输入格式，如果不写，qemu-img 会自动探测。-O：输出格式，注意大写，与-f刻意区分。-c：输出 qcow2 开启压缩。- 后面的两个文件名分别是输入与输出。
转换过程中值得注意的坑有两个。
第一个是输出文件不能和输入文件重名，这看起来是废话，但我在实际工作中真见过有人原地转换导致文件写坏。
第二个是转换是按"分配过的数据块"来的，对于 qcow2 输入，默认只转换实际有数据的块，因此转换完成后得到的文件虚拟大小不变，但物理占用可能远小于源镜像。这个特性在做"压缩迁移"时很有用。
bash复制# 看完效果
ls -lh disk.raw disk.qcow2
qemu-img info disk.qcow2
2.2 跨平台转换：qcow2 转 vmdk 的典型用处
如果你需要把 KVM 里的镜像拿到 VMware Workstation 或 ESXi 里用，就得转 vmdk。注意 vmdk 又分多种子格式，qemu-img 输出 vmdk 时默认是 monolithicSparse（单文件稀疏），对 VMware 兼容性较好。
bash复制qemu-img convert -p -f qcow2 -O vmdk ubuntu.qcow2 ubuntu.vmdk
转完后如果 VMware 打开报错"此虚拟机的磁盘配置不支持"，多半是缺少一个描述文件 .vmdk 对应的 .vmx 磁盘控制器类型不一致。此时可以检查一下 vmdk 的头部信息，或者用 VMware 的 vmkfstools 再转一次（这在 ESXi 环境里尤其常见）。
反过来，从 vmdk 转 qcow2 也一样，只要 -f vmdk -O qcow2 即可。
2.3 查看镜像信息：qemu-img info 的字段解读
info 是我们排查问题时的"第一现场"：
bash复制qemu-img info ubuntu.qcow2
输出示例：
text复制image: ubuntu.qcow2
file format: qcow2
virtual size: 50 GiB (53687091200 bytes)
disk size: 8.2 GiB
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 clean_os 284 MiB 2024-05-01 19:22:33 00:01:12.193
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: true
refcount bits: 16
corrupt: false
这些字段里，virtual size 是虚拟磁盘大小，disk size 是实际占用的宿主机物理空间，cluster_size 是前面说的簇大小，compat 是 qcow2 的兼容版本，corrupt 如果为 true 就需要立刻用 check 修复。如果你的镜像文件是关联镜像（差量盘），info 还会显示 backing file 路径和 backing file 格式。
注意：info 只能反映镜像本身状态，无法确认客户机内部的文件系统是否有问题。想验证数据完整性，还需要客户机操作系统配合。
3. 镜像诊断与修复：check 命令的正确使用姿势
虚拟化环境里，异常断电、宿主机关机不干净、磁盘空间写满，都可能导致 qcow2 镜像出现元数据损坏。这时第一反应别是重装系统，先用 qemu-img check 诊断。
3.1 check 命令输出解析
bash复制qemu-img check -r all disk.qcow2
-r 参数有两种修复级别：
-r leaks：只修复泄漏的簇（数据块被标记为已使用，但没有被任何文件引用）。-r all：修复所有能修复的问题，包括簇泄漏和元数据不一致。
执行后输出：
text复制Leaked clusters 34
Corruptions 0
如果有泄漏簇，说明曾经有数据块未正确清理，但通常不影响虚拟机继续使用。Corruptions 不为 0 则要警惕，可能涉及活跃数据。
3.2 实战案例：qcow2 镜像开机黑屏的修复过程
有一次维护一台测试机，宿主机突然断电，重启后虚拟机黑屏无法引导。我先在宿主机上执行：
bash复制qemu-img check -r all /data/kvm/vm01.qcow2
结果报了 2 处 corruptions。修复后，虚拟机仍无法引导，因为 qcow2 的修复只处理镜像层的元数据，不能修复客户机内部文件系统的损坏。随后我用一个应急系统盘引导，进 fsck 修复了 ext4 文件系统，才恢复正常。
这里想传达的经验是：qemu-img check 是"镜像层"的修复工具，不是客户机文件系统的修复工具。镜像层修复完成，只能保证你还能打开这个文件，至于里面的 /etc/fstab、引导程序是否正常，那是另一个维度的问题。
3.3 什么时候不要用 check 修复
如果镜像 corrupt: true 且是线上生产机的唯一样本，没有备份，那我强烈建议你先复制一份镜像文件，对副本执行 check。因为 -r all 在某些极端情况下会把误判的数据块重新正确分配，但也可能"修"掉一些边缘数据。虽然这个概率很小，但生产数据无小事。
再一个常见场景是 backing chain 里的镜像损坏。关联镜像（差量盘）修复时需要连同 backing file 一起验证，单独修复某个链节可能造成链断裂。此时最好先备份整条链，然后在副本上测试修复。
4. 快照管理与 resize 扩容：高频进阶操作全拆解
qemu-img 的快照功能主要分两类：内部快照和外部快照。很多人会混淆，我分别讲清楚。
4.1 内部快照：qcow2 自带的时光机
内部快照是把某个时刻的整盘状态保存在同一个 qcow2 文件里，用 qemu-img snapshot 可以管理。
bash复制# 创建快照
qemu-img snapshot -c clean_before_update vm.qcow2
# 查看快照列表
qemu-img snapshot -l vm.qcow2
# 执行快照回滚
qemu-img snapshot -a clean_before_update vm.qcow2
# 删除快照
qemu-img snapshot -d clean_before_update vm.qcow2
内部快照的优点是管理简单，一个文件就是一个完整的虚拟机。缺点是快照一旦增多，文件体积迅速膨胀，而且回滚是全盘级别的，不能选择性地恢复某个文件。所以我的建议是：内部快照适合做短期、临时性的操作前备份，不适合做长期保留策略。
4.2 外部快照：backing chain 与增量备份
外部快照又称差量镜像，最大的特点是"快照文件小、创建速度快、可以无限嵌套"。它对应的是 qemu-img create -b 命令：
bash复制# 基于当前盘 base.qcow2 创建差量镜像 overlay.qcow2
qemu-img create -f qcow2 -F qcow2 -b base.qcow2 overlay.qcow2
这里的 overlay.qcow2 称为 overlay，base.qcow2 称为 backing file。虚拟机用 overlay 启动，写数据时写到 overlay，读数据时先查 overlay，不命中才去 base 读。这个机制是增量备份和"黄金镜像"克隆方案的技术基础。
外部快照的好处是回滚只需删除 overlay 或重新指向 base，对 base 完全无侵入。但链条变长后，读性能会下降，且任意一环丢失都会导致整条链不可用。因此链条不是越长越好，及时做 commit 合并才是正解（后文有专门章节）。
4.3 resize 扩容：给虚拟机磁盘"加量"的完整流程
当客户机磁盘空间不足，我们要先在宿主机层面增加 qcow2 镜像的虚拟大小：
bash复制qemu-img resize vm.qcow2 +50G
注意这里的按量增长（+50G）和指定最终大小（200G）都行，但 qcow2 扩容只对"镜像虚拟大小"生效，客户机里的分区表和文件系统需要另外处理。
我在实际项目中最常用的一套完整操作是：
- 关闭虚拟机或用
virt-resize对离线镜像操作。 - 执行
qemu-img resize vm.qcow2 +50G。 - 用
virt-filesystems查看当前分区布局。 - 用
virt-resize或启动一台救援虚拟机，在客户机内部用growpart扩展分区，用resize2fs扩展文件系统。
bash复制# 在救援虚拟机或客户机内
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1
特别注意：qemu-img resize 支持缩容，格式为 qemu-img resize vm.qcow2 -10G 或指定一个更小的大小。但缩容非常危险，因为镜像无法智能判断哪里是空闲块，直接缩小极可能切断分区边界导致数据损坏。如果确实需要缩容，建议用 virt-resize 把源盘内容整体复制到一个更小的新盘上，而不是对原盘做 resize。
4.4 一次扩容踩坑实录：客户机不识别新磁盘
前阵子我遇到一个案例：执行完 resize 后，客户机在 fdisk -l 里看不到新增空间。排查下来原因是虚拟机的磁盘总线类型是 virtio-blk，但客户机内核没有自动重新扫描设备。解决办法是在客户机内执行：
bash复制echo 1 > /sys/block/vda/device/rescan
或者在宿主机侧用 virsh blockresize 通知客户机重新识别。如果是 IDE 或 SATA 设备，通常需要重启虚拟机才能识别。这也提醒我们：resize 之后不是马上"生效"，往往还需要在客户机和存储两个层面协同操作。
5. 关联镜像链处理：rebase 和 commit 的深度理解
外部快照和差量盘产生后，就需要理解 backing chain。链式结构让管理变得复杂，但 qemu-img 提供了两个离线工具来维护这条链：rebase 和 commit。
5.1 commit：把 overlay 合并到 backing file
qemu-img commit 的作用是把 overlay 中相对于 base 的修改写回 base，这样链条就缩短了一节。
bash复制# 将差量镜像 overlay.qcow2 合并到其 backing file 中
qemu-img commit overlay.qcow2
执行 commit 前务必确保 overlay 没有被正在运行的虚拟机使用，这是离线操作，不能热执行。合并完成后，base.qcow2 的文件大小会增加，因为它吸收了 overlay 中的差异数据；overlay 则不再需要。
5.2 rebase：重新指定 backing file 的神奇能力
rebase 字面意思是"重定基线"，它可以在不改变当前镜像数据的前提下，把它依赖的 backing file 换成另一个。
例如当前链是 overlay2 -> overlay1 -> base，你希望把 overlay2 直接基于 base，也就是缩短链条，可以执行：
bash复制qemu-img rebase -b base.qcow2 overlay2.qcow2
如果加 -u 参数，则为"不安全模式"，只更新 backing file 记录，不检查实际数据差异：
bash复制qemu-img rebase -u -b base.qcow2 overlay2.qcow2
不加 -u 时，rebase 会逐块比较新旧 backing file 的数据，把不一致的部分复制到 overlay 里，这个过程可能相当耗时。如果新旧 backing file 内容一致（比如只是换个存储路径），用 -u 更新链接即可，效率极高。
5.3 rebase 的真实项目场景：迁移 storage 路径
我在维护一套使用 NFS 存储的 KVM 环境时，经常要把镜像从旧 NFS 服务器迁移到新存储。迁移后，所有 backing file 路径都失效了。如果逐个重新创建 overlay，工作量很大。这时候 rebase 的 -u 就派上用场了：
bash复制# 假设 overlay.qcow2 的 backing file 原来指向 /old_nfs/base.qcow2
# 迁移到新路径后
qemu-img rebase -u -b /new_nfs/base.qcow2 overlay.qcow2
只要 /new_nfs/base.qcow2 和原来的 base 是同一个文件（迁移复制过去的），这个过程秒级完成。如果 base 有变化，就必须去掉 -u 做全量比对，这时要注意磁盘空间，因为它可能在 overlay 里写入大量"数据块"。
5.4 链条断裂的处理思路
backing chain 最常见的故障就是 backing file 找不到或格式不匹配。qemu-img info 会提示 backing file format，但有些老版本镜像不写 backing format 字段，导致新版本 QEMU 在启动时拒绝运行。
解决办法有两个：
- 用
qemu-img rebase -u -F qcow2 -b base.qcow2 overlay.qcow2显式重设 backing format。 - 用
qemu-img amend -o backing_fmt=qcow2 overlay.qcow2修改镜像头信息。
这块内容比较冷门，但一旦遇到，排查起来非常痛苦。提前知道这两个命令，能省下大量时间。
6. 综合实战：从零构建一套"黄金镜像 + 差量盘"虚拟机部署流程
前面知识点拆得比较细，现在我把它们串成一个完整的实战项目。这里的方案很常用于开发测试环境或桌面虚拟化：一个基础黄金镜像，批量生成多个差量盘作为不同虚拟机的磁盘，既省空间又能秒级部署。
6.1 准备黄金镜像
首先在一台临时虚拟机上安装好操作系统，完成常用环境初始化（yum/apt 源、基础软件、SSH 密钥等），然后关停虚拟机，在宿主机上做两件事：
- 对该镜像做一次内部快照，作为初始干净状态。
- 将镜像转换为模板 qcow2，并压缩。
bash复制qemu-img snapshot -c base_clean vm_source.qcow2
qemu-img convert -p -f qcow2 -O qcow2 -c vm_source.qcow2 gold.qcow2
6.2 批量创建差量盘
有了 gold.qcow2，就可以用一条命令批量生成多个 overlay：
bash复制for i in 01 02 03; do
qemu-img create -f qcow2 -F qcow2 -b gold.qcow2 vm-$i.qcow2
done
查看效果：
bash复制qemu-img info vm-01.qcow2
你会看到 backing file: gold.qcow2，并且 vm-01.qcow2 的物理占用只有约 200K 左右。这就是写时分配和 backing chain 带来的"测地效果"。
6.3 日常备份与快照管理
在这样的架构下，对某台虚拟机的备份不必整盘复制，只需备份对应的 overlay 外加一份 gold 模板的校验信息。更稳妥做法是定期对 gold.qcow2 做一次全部备份，对各 overlay 做增量备份。
bash复制# 将某台虚拟机的 overlay 导出为独立、完整的 qcow2 镜像，适合归档
qemu-img convert -p -f qcow2 -O qcow2 vm-01.qcow2 vm-01-backup.qcow2
convert 的妙处在于：如果输入是带 backing file 的 overlay，convert 会把 base 与 overlay 的数据合并输出到新文件中，新文件不依赖任何 backing file，是独立的。这也是很多人误以为 convert 只能做格式转换，实际上它同时承担了"扁平化合并"的职责。
6.4 回滚策略
如果某台虚拟机被搞坏了，回滚有两种策略：
- 最省事：把 overlay 文件删除，重新从 gold.qcow2 创建同名 overlay，相当于恢复出厂状态。但这样会丢失这台虚拟机自创建以来所有数据。
- 更精细：用内部快照。在 overlay 正常时做
qemu-img snapshot -c ok_xxxx vm-01.qcow2，出问题时回滚到这个快照。
结合使用是王道：gold + overlay 提供了部署效率，内部快照提供了短期的"后悔药"。
6.5 演练中的性能观察
实践中我发现一个有意思的现象：差量盘刚创建时，虚拟机 IO 表现略优于完整盘，因为操作系统安装后的"只读部分"大量命中 backing file 的缓存；但运行一段时间后，overlay 膨胀变大，读路径变长，性能会逐步回落。这是正常现象，不要以为是出了故障。
如果某台差量盘的 overlay 增长过快，通常说明这个虚拟机里有大量随机写，比如数据库或日志服务。对这种负载，我建议不要长期挂在 gold 上做差量，而是定期 commit 合并，或者直接创建独立完整盘。
7. 性能调优与常见报错排查：qemu-img 使用中的避坑清单
最后这一部分，我把平时支持同事和社区里高频出现的坑集中梳理，同时附带一些性能参数调整建议。
7.1 预分配、缓存与写性能的权衡
- cache=none：
qemu-system-x86_64 -drive file=vm.qcow2,cache=none。绕过宿主机 page cache，直接使用 O_DIRECT 访问磁盘镜像。对客户端 IO 延迟稳定，但写性能受限于物理盘。 - cache=writeback：允许宿主机缓存写数据，性能好但理论上有掉电丢失风险。单机测试环境常用，生产环境如果存储有 UPS 和 RAID 电池保护，也大量采用。
- discard=unmap：配合客户机 TRIM，可以让被删除的块在 qcow2 中真正释放，避免镜像文件只增不减。
创建虚拟机时我会把 discard=unmap 打开，并在客户机里开启 fstrim 定时任务，这能有效控制 qcow2 文件持续膨胀。
7.2 经常踩的坑集合
以下是我从实际工单里整理出来的高频问题，供你排查时对照：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 虚拟机启动后提示"backing file"相关错误 | 镜像头里 backing 路径错位或缺少 backing_fmt | qemu-img rebase -u -F qcow2 -b 正确路径 overlay.qcow2 |
| 挂载时提示"Could not read image for determining its format" | 镜像文件本身不是有效格式或权限不足 | 检查文件权限；file 命令看头部；用 qemu-img info 探测 |
qemu-img resize 后客户机不识别 |
未在客户机里 rescan，或分区表没有扩展 | 驱动 rescan，或 growpart + resize2fs |
| 快照回滚后数据"丢失" | 回滚覆盖了回滚点之后写入的数据 | 回滚是整盘级别，操作前务必确认 |
convert 过程中进度条卡住不动 |
大文件 + 压缩较慢，或输出磁盘空间不足 | 耐心等待，同时检查输出目录磁盘空间 |
| 差量盘 volume 突然暴涨 | 客户机有大量写入，或未启用 TRIM | 开 discard=unmap，客户机定期 fstrim |
qemu-img check 提示 refcount 溢出 |
qcow2 的 refcount 表出现过 UAF 类似问题 | 用 -r all 修复，极严重时只能重建镜像 |
7.3 一个隐蔽问题：低版本 QEMU 打开高版本创建的镜像
如果 A 机上用 QEMU 7.x 创建的 qcow2，拿到 QEMU 4.x 的宿主机上运行，可能报错 "Unsupported cluster size" 或 "Invalid L2 table entry"。原因是新版本可能使用了旧的 QEMU 不认识的特性位。解决办法是在创建镜像时指定兼容级别：
bash复制qemu-img create -f qcow2 -o compat=1.1 ubuntu.qcow2 20G
compat=1.1 是相对保守的兼容级别，几乎所有 QEMU 都支持。新版 qcow2 默认可能是 compat=1.1 或更高版本，如果你需要在多个版本 QEMU 之间来回迁移，建议显式指定。
7.4 给老手的几条经验
- 操作生产镜像前，先用
cp --reflink=auto做一次 CoW 副本，很多事故能避免。 qemu-img map可以查看镜像数据块的分配情况，用它对稀疏文件做"瘦身"很有效：bash复制
qemu-img map vm.qcow2- 把 qemu-img 相关命令写进备份脚本时，注意
convert是 CPU 密集型，建议nice降优先级，避免影响线上业务。 - 定期用
qemu-img check -r all -f qcow2对关键镜像做巡检，就像磁盘的fsck一样，越早发现问题代价越小。
qemu-img 这个工具，平时用的时候不觉得多重要，但真遇到格式不识别、链条断裂、空间无故被占用这些问题时，能救命的往往就是它。我写这篇手册的初衷，也是希望大家在使用它的过程中少走点弯路。以上各节内容都是我实际维护环境里反复敲过、验证过的东西，你照着操作基本不会出大问题。但虚拟化环境千差万别，如果你的场景与我举例的有所不同，请一定先在测试机上演练一遍再上生产。