1. 一场磁盘告警引发的思考qcow2 与 raw 到底差在哪1.1 从一次“文件比磁盘还小”的诡异现象说起先说个真实经历。某天凌晨一套 KVM 环境的宿主机报警说/var/lib/libvirt/images分区使用率到了 91%我登录上去一看里面躺着十几个虚拟机的磁盘镜像文件。其中有一台数据库虚拟机的镜像文件大小只有 20G 出头但虚拟机的df -h显示根分区已经用了 78G。合着这个虚拟机的数据量已经远超镜像文件本身的大小了当时第一反应是监控脚本写错了后来才反应过来——这台虚拟机的磁盘格式是 qcow2属于稀疏文件镜像文件的大小不表示虚拟机实际占用的物理空间也不表示它给客户机暴露的逻辑磁盘大小。从那次之后我就把 KVM 环境里两种主流磁盘格式 qcow2 和 raw 的基本特性、适用场景、性能差异彻底梳理了一遍。很多刚接触虚拟化的朋友会把“虚拟磁盘格式”和“磁盘镜像文件大小”搞混。简单说qcow2 是 QEMU 的写时分配格式它只占实际写入数据需要的空间raw 则是一个裸的块设备镜像或者说它就是直接把一块磁盘的所有扇区按顺序复制成一个文件。raw 格式因为缺少元数据层读写路径更短但它的文件大小通常等于虚拟磁盘容量除非你用特殊方式创建稀疏文件。这两种格式在 KVM 环境下是最常被拿来对比的没有绝对的好与坏只有适不适合你的业务场景。1.2 两个词说清分配机制按需取用 vs 一口吃下要理解 qcow2 和 raw 的本质区别先记住两个关键概念按需分配和预分配。qcow2 默认是“按需分配”也就是 thin provisioning。虚拟机只写了一个 1G 的文件qcow2 镜像文件在宿主机上就只占 1G 左右还要算上一点元数据开销。虚拟机不断写数据镜像文件才不断变大。这种机制可以极大节省宿主机存储空间尤其适合那种“创建了很多虚拟机但实际写入量都不大”的环境。它的内部结构分了三层有 header、L1 表、L2 表数据块是按需分配的写数据时要先查映射表找到对应位置如果位置不存在就分配新块再写入。raw 格式就简单直接得多。它本身没有快照、没有元数据、没有压缩就是一块裸盘。如果你用qemu-img create -f raw disk.raw 100G创建镜像文件会立刻占满 100G取决于宿主文件系统因为 raw 格式默认是预分配。但这里有个容易忽略的细节你完全可以用truncate -s 100G disk.raw或qemu-img create -f raw -o preallocationoff disk.raw 100G创建一个所谓的“稀疏 raw 文件”文件看起来有 100G实际占用只有几K后面用到哪块才分配哪块。所以从存储分配的角度看qcow2 天生是稀疏的raw 则可疏可密。但如果你把 raw 做成稀疏文件它的“稀疏”是宿主文件系统比如 ext4、xfs帮你实现的不是 raw 格式自己的特性。换句话说qcow2 的分配管理是自带的raw 的分配管理是借别人的。对比维度qcow2raw预分配raw稀疏文件创建时占用空间极小约 200K 起等于虚拟磁盘大小极小写入时空间增长自动按需增长不增长已全部分配由文件系统按需分配元数据开销有L1/L2 表无无该格式是否自带稀疏能力自带不依赖文件系统依赖文件系统支持qcow2 的按需分配虽然省空间但也带来一个天然问题写入路径变长了。物理服务器上跑数据库、跑高频随机 IO 的场景如果空间不紧张很多人宁愿用 raw 省掉那层映射开销。而如果你的环境是开发测试、云计算平台的多租户虚拟化qcow2 的节省空间能力就非常值钱。这就要看性能和便利性怎么权衡了。2. 性能对比实测同样跑业务差距藏在元数据和快照里2.1 顺序读写与随机 IO 的表现差异很多人一上来就问我“qcow2 性能是不是比 raw 差很多”我的回答是看场景看负载看后端存储。纯顺序读写的场景比如虚拟机里做磁盘镜像拷贝、批量文件传输raw 确实有优势但没网上说的那么夸张。qcow2 在读路径上需要先读 L1/L2 表找到数据块位置再读实际数据正常情况下这张映射数据不大可以被缓存命中所以顺序读的损耗可能只有几个百分点。但在写路径上qcow2 遇到新分配的块要额外执行一次元数据更新顺序写的性能差距会明显一点。随机 IO 的场景差距才会拉开。数据库类负载比如 MySQL、PostgreSQL会产生大量小文件随机读写的 IO。raw 格式下宿主机把请求直接翻译成对镜像文件的偏移量读写路径非常短。qcow2 格式下每次 IO 都要经历“虚拟机发出请求 - 找到对应的 L2 表项 - 确认数据块位置 - 读写实际数据”的过程。如果 L2 表不在缓存里就会多一次甚至几次磁盘寻道随机读写性能就会掉下来。我用fio在同样一台宿主机上做过一轮简单测试后端都是同一块企业级 SSD虚拟机里都跑 CentOS一个用 qcow2一个用 raw。结果大致是这样的不同硬件会有偏差只作参考测试项qcow2raw差距说明顺序读128K 队列深度 16约 1200 MB/s约 1500 MB/sraw 高约 25%元数据查询拖了后腿顺序写128K 队列深度 16约 850 MB/s约 1100 MB/sraw 高约 30%新块分配开销明显随机读4K 队列深度 32约 120K IOPS约 140K IOPSraw 高约 17%缓存命中后差距缩小随机写4K 队列深度 32约 45K IOPS约 80K IOPSraw 高将近一倍qcow2 写入放大严重随机写差距大是因为 qcow2 本身存在“写时分配”的额外消耗。每当写入一个数据块如果该块之前是未分配的先要分配一个新块再把数据写进去同时更新 L2 表。如果频繁覆盖已有块还要处理块引用计数。这些元数据操作叠加在用户 IO 之上就形成了写入放大。而 raw 格式没这些步骤数据写到哪里就是哪里。2.2 快照机制如何悄悄拖慢写入qcow2 的一大卖点就是支持快照但快照也是它性能下降的常见原因。默认情况下你在 KVM 里用virsh snapshot-create-as给 qcow2 虚拟机拍快照QEMU 会把新数据写入一个新的镜像分支原来的数据块变成只读。这样设计的好处是快照点之前的镜像文件保持原样可以随时回退。问题在于如果你在快照之上持续运行业务一旦有写操作落在那些“快照前已经分配并被读入缓存”的块上虚拟机就需要读取旧数据copy-on-write 的 read-modify-write再写入新数据。这一读一写IO 延迟就上去了。我见过一个开发环境qcow2 虚拟机挂着三个快照长期不合并每次提交代码触发一次全量刷新那个虚拟机的磁盘响应时间能从 5 毫秒飙到 300 多毫秒。后来我把快照合并完性能立刻恢复了。raw 格式本身不支持快照但你可以借助后端方案实现类似能力。最常用的思路是底层使用 LVM 卷给每个虚拟机分配一个 LV然后用lvcreate -s做 LVM 快照。LVM 快照和 qcow2 快照不一样它的 COW 机制由内核的 Device Mapper 实现性能损耗比 qcow2 自带的快照小而且不光是磁盘格式层面的功能整个文件系统都能被一致地快照。缺点是要预先规划 VG 空间快照卷也要预留容量。如果你需要频繁快照、回退、保存某个时刻的磁盘状态qcow2 的整合程度最高。但如果你更在意长时间稳定性能那就要谨慎使用快照。要么不用要么用后及时合并别留下一堆“性能债务”。2.3 缓存策略cache 模式与格式的配合既然说到性能就绕不开 KVM 的缓存策略。很多人把缓存策略和磁盘格式混在一起对比其实这俩是不同层面的东西。cachewriteback、cachenone这些是 QEMU 层面控制 “宿主机页缓存如何处理磁盘 IO” 的参数不会改变 qcow2 或 raw 的元数据结构但会影响最终性能表现。我的经验是在 Linux 宿主机上如果你用的是 raw 格式的镜像且把它放在 SSD 上那cachenone加上ionative是比较稳的组合。这样 QEMU 会绕过自身的页缓存直接使用 AIO 原生接口发 IO对数据库这类有自己缓存机制的应用最友好避免了双缓存导致的资源浪费。qcow2 格式则稍微保守一点建议用cachewriteback因为 qcow2 的元数据更新比较频繁让宿主机页缓存帮忙兜着能降低一些 IO 波动。缓存模式raw 下表现qcow2 下表现适用场景writeback性能好但断电有丢数据风险推荐元数据更新更平滑开发测试、可接受掉电不完全一致的场景none native推荐路径最短性能透明可用但 qcow2 映射表 miss 时会放大延迟生产数据库、高随机 IOunsafe性能最强数据安全最差性能提升明显但不建议临时跑批可随时重置我并不建议你把缓存参数照抄到一个生产环境里因为宿主机的 RAID 卡缓存、BBU、存储网络带宽都会干涉最终效果。调优的正确姿势是固定磁盘格式分别测不同 cache 模式记录 P95 延迟和 IOPS再根据业务类型做决定。3. 选型决策表开发机、生产库、临时测试到底该用谁3.1 选型维度拆解空间、性能、运维复杂度抛开纸面参数选格式前先问自己三个问题宿主机存储够不够虚拟机 IO 压力有多大团队对快照、备份等运维能力要求多高第一个是空间问题。如果你在物理机上开 20 台虚拟机每台逻辑盘都开了 100G但实际平均只用了 30G那 qcow2 明显划算总占用可能只需要 600G 左右如果全用预分配的 raw直接就是 2000G 没了。很多虚拟化集群愿意上 qcow2就是因为它能显著提高存储利用率。第二个是性能问题。数据库、重负载应用尤其是有大量随机写的小虚拟机raw 的后端写放大更小长期运行更稳。第三个是运维复杂度。qcow2 的快照、克隆、压缩、加密都是命令行内建能力raw 想有类似功能得借助 LVM、zfs、btrfs 这些宿主文件系统对团队的技术栈要求更高。还有一点常常被忽略虚拟磁盘格式和宿主机文件系统的耦合度。raw 格式存放在任意文件系统上性能很大程度取决于文件系统的分配策略qcow2 则多了一层自己的块管理。如果宿主机用 XFS、ext4两种格式都能跑。如果底层是 ZFS那 raw 配合 ZFS 的块引用快照反而能获得比 qcow2 更好的数据管理体验这时不一定非要选 qcow2。3.2 给不同场景的推荐组合基于这些维度我一般给不同场景开不同的“处方”。开发测试环境首选 qcow2。空间利用率高快照回退方便配合qemu-img create -b基础镜像还能实现秒级创建开发机。一个 20G 的基础镜像后面挂 8 台开发机每台只占几百 M 的差异数据量。测试人员随便改系统、随便折腾出了问题恢复快照就行成本极低。生产数据库虚拟机我通常推荐 raw 预分配同时配合 LVM。数据库需要稳定的 IOPS 和低延迟raw 格式少了一层元数据转换更符合“稳定压倒一切”的原则。用 LVM 做底层卷管理可以在线扩展虚拟机磁盘还支持 LVM 快照是生产环境里比较扎实的组合。不过 raw 注意保持一定的宿主机存储余量因为文件创建后立即占满。CI 机器人 / 临时测试机如果你有一个 KVM 集群在跑 CI比如每次代码提交都拉起几台虚拟机跑集成测试跑完就销毁那 qcow2 还是最优解。你可以准备一个“干净系统”的基础镜像多个临时虚拟机用同一个 base 镜像创建销毁时只删除差异盘宿主机空间压力很小。如果再配一个zstd压缩的 qcow2 镜像作为镜像仓库创建虚拟机的速度会更快。网盘、对象存储网关这类 IO 慢但空间大的应用这种应用一般是“大带宽顺序读写但延迟不敏感”raw 和 qcow2 都能胜任。这里更该关注的是底层存储介质和网络而不是格式。我觉得别为了追求性能盲目上 raw毕竟 qcow2 的压缩特性在这种场景下能省不少空间。下面这张表总结一下我的推荐场景推荐格式理由开发测试机qcow2省空间快照方便克隆快生产数据库raw LVM低延迟无元数据开销快照够用CI 临时实例qcow2 backing file秒级创建空间占用极低长期归档镜像qcow2 压缩减小镜像体积完整保留虚拟盘状态大容量文件服务器raw 或 qcow2 均可瓶颈在存储介质格式影响小4. qcow2 独有的高级特性快照、压缩、加密与后备盘4.1 内置快照与外部快照的区别既然聊 qcow2就必须把它最拿得出手的几项高级能力说清楚。前面提到的快照细分下来有两种玩法内置快照internal snapshot和外部快照external snapshot。内置快照是把快照状态直接保存在同一个 qcow2 文件里用virsh snapshot-create-as --disk-only或者qemu-img snapshot -c创建。它的好处是管理简单一个镜像文件自带多个历史状态回退时用virsh snapshot-revert一条命令搞定。缺点是文件会变得越来越大因为旧数据块不能被回收快照多了之后虚拟机的写性能明显下降。外部快照就灵活多了。创建时 QEMU 会生成一个新的 qcow2 文件作为当前活跃层原来的 qcow2 变成只读的基础层。你可以一层一层叠形成一个快照链。这种设计非常契合“想随时回到某个历史状态、又不想让单一文件膨胀失控”的场景。运维上要用virsh blockcommit把上面层的数据合并回底层或者用virsh blockpull把底层合并到顶层操作链条不复杂但概念容易绕新手经常分不清 commit 和 pull 的方向。内部快照链不会污染镜像文件之外的东西但生产环境我更倾向外部快照因为合并失败还能用底层文件单独恢复到某个时点。我这套习惯是在一次“内部快照把文件撑到 300Gqemu-img check 还报了多处不一致”的教训之后形成的。4.2 压缩与加密对性能的实际影响qcow2 支持-o compressionon可以用qemu-img convert -c把现有镜像重新转换成压缩格式。压缩带来的空间收益非常可观尤其是安装好系统、清理完缓存后的基准镜像体积可能减少一半。代价是 CPU 需要在读写时进行压缩/解压操作所以压缩镜像的 IO 延迟会比不压缩的略高CPU 占用也更高。我在一台只有 4 核的宿主机上做过测试5 台压缩 qcow2 虚拟机同时跑编译任务整体耗时比不压缩多出约 15%-20%但空间节省了 40% 以上。空间紧张、CPU 繁忙程度不高的环境压缩是收益大于代价的。加密这块qcow2 支持 AES 加密创建时指定-o encrypt.formatluks就能给磁盘镜像加上一层保护。它的原理是给虚拟磁盘的数据块加密没有密钥就无法读取镜像内容。这对移动介质上的虚拟机、外包运维场景很有用。但加密的代价不只是性能还有密钥管理的复杂度。如果你忘了密码那整块虚拟盘的数据基本等于没了系统层面的文件恢复工具再好都救不回来。所以我不建议在性能敏感环境里开加密如果确实有合规需求不如走系统层面加密或者用宿主机文件系统的加密能力。4.3 backing file 的继承链玩法这是 qcow2 比 raw 灵活得多的一块。用qemu-img create -f qcow2 -b base.qcow2 -F qcow2 child.qcow2创建带后备文件backing file的镜像子镜像只记录与基础镜像的差异数据。这种设计经常被用来做“黄金镜像 差异磁盘”的分层体系。实际管理上我建议遵循两个原则第一基础镜像必须是完全干净且相对固定的版本不打补丁、不装多余软件。第二子镜像生命周期结束后要及时清理避免底层基础镜像改了几百个子镜像的引用关系变得一团乱麻。KVM 不会强制校验子镜像和 base 镜像的匹配关系但如果你误删了 base 文件所有依赖它的子镜像就全废了。在libvirt里带 backing 的 qcow2 通常用于快速生成多台同配置虚拟机比如考试环境里一次给 20 个学员开同样配置的 Linux 实验机。创建时只是创建一个很小的差异文件几秒钟就能把虚拟机定义好等学员开始操作才慢慢分配空间。这正是 qcow2 对比 raw 最大的商业模式级优势——省的不只是容量还有创建时间。5. 转换与迁移实操从 qcow2 到 raw 的完整流程复盘5.1 qemu-img convert 的核心参数与目标大小预估没人能保证一种格式用一辈子。很多时候开发环境里用 qcow2 写满了一堆数据要搬到生产环境做数据库就得把它转成 raw。这时候核心工具就是qemu-img convert。转格式前先做两个准备第一虚拟机最好关机或者至少确保文件系统是静态一致状态。我在运行中转过一次结果客户机文件系统里出现了少量不一致虽然fsck能修但没必要冒这个险。第二用qemu-img info source.qcow2看当前磁盘的虚拟大小和实际占用这决定了目标 raw 文件要多少空间。比如虚拟磁盘是 100G但 qcow2 实际只占了 30G转成 raw 后目标文件在预分配模式下就是 100G如果宿主机空间不够 100G你就得先用truncate建一个稀疏 raw转换完成后看du -h确认实际占用。标准的转换命令是这样# 查看源镜像信息 qemu-img info source.qcow2 # 转换为 raw-p 显示进度-f 指源格式-O 指目标格式 qemu-img convert -p -f qcow2 -O raw source.qcow2 dest.raw转换过程本质上是按“虚拟磁盘布局”逐块复制数据目标文件大小等于虚拟磁盘的容量而不是源镜像的实际占用。所以如果你空间紧张最好先把源镜像里的空闲空间清理掉。Linux 虚拟机可以用fstrim或virt-sparsify工具瘦身Windows 虚拟机需要在系统里执行“优化驱动器”里的 TRIM 操作。瘦身后再转换目标 raw 的实际占用会小很多。另外qemu-img convert也支持直接加压缩选项比如# 把 raw 转成 qcow2 并压缩 qemu-img convert -p -f raw -O qcow2 -c source.raw dest.qcow2如果你转换的目的是为了归档备份压缩选项就很值。如果是为了继续跑生产负载我一般不加-c避免无谓的 CPU 开销。5.2 转换过程中最容易踩的三个坑第一个坑是“目标文件被占用了却不知道”。我在一次在线迁移时目标虚拟机还没关机又顺手执行了向目标路径写入的 convert 命令结果目标文件被 QEMU 进程锁定convert 直接报错。正确流程是先virsh shutdown关闭虚拟机确保镜像文件不再被进程占用再开始转换。第二个坑是“引导方式不匹配”。qcow2 和 raw 本身不涉及引导差异但有些老系统在安装时生成的/boot/grub2/grub.cfg里root 设备用的是设备 ID 或/dev/vda转换完镜像挂到一个不同的 virtio 设备编号上就可能出现 kernel panic。遇到这种情况不要急着怀疑转换失败先用virt-rescue或手动挂载目标镜像检查/etc/fstab和 grub 配置修正设备路径后再启动。现在的发行版大多用 UUID 定位根分区这个问题已经少多了但老镜像还是能碰上。第三个坑是“空间判错转换到一半磁盘写满”。比如虚拟磁盘 200G宿主机空闲只剩 180G你硬转 raw跑到 90% 就报No space left on device目标文件直接损坏。我的习惯是先qemu-img convert到一个同分区的临时路径等完成并校验后再mv到最终位置。虽然多一次拷贝但至少不会破坏原有镜像。同时转换前用df -h确认目标分区至少得有“虚拟磁盘容量 10%”的余量。5.3 就地转换的思路临时盘加重启方案如果你不想把虚拟机关太久可以采用“临时盘就地转换”的方式。大概流程是这样在宿主机上新分配一块容量足够的存储空间把 qcow2 转换成 raw 写到临时路径然后直接修改虚拟机的 libvirt XML 定义把磁盘路径指向新的 raw 文件最后启动虚拟机验证业务。验证没问题再删除旧镜像。这套方案的关键点是新 raw 文件必须与原虚拟机的磁盘总线类型、设备名保持一致否则客户机里的/dev/sda可能变成/dev/sdb。如果用的是 SATA 或 virtio-blk通常不改也没事但我还是建议在 XML 里保持原样避免节外生枝。另一个就地转换的例外技巧如果你只是想从 qcow2 换成 raw 以获得更低延迟但虚拟机已经承载了核心业务不好中断那就先做一次文件系统层面的快照比如 LVM 快照然后把快照转成 raw再把业务切过去。这种方式停机时间可以控制在几分钟内前提是网络、存储规划得当。5.4 反向迁移什么时候该从 raw 转回 qcow2反向转换的需求一点都不少。我遇到最多的是这两个理由一是想把生产环境的一台 raw 虚拟机变成开发测试机需要精简单机并引来快照能力二是宿主机规划存储空间后发现 raw 太占地方全部转成 qcow2 能做到空间减半。命令几乎没有差别只是把源格式和目标格式反过来qemu-img convert -p -f raw -O qcow2 source.raw dest.qcow2从 raw 转 qcow2最大的好处是转完之后文件体积会立刻变小因为 qcow2 会按实际占用分配块。但有个点要注意qcow2 默认不做空洞识别如果你在 raw 里删了很多大文件转换时这些空闲块也会被当成普通数据写进目标文件。先对客户机执行fstrim再转换效果会好很多。还有转成 qcow2 之后如果你计划长期依赖快照务必定期qemu-img check检查一致性别让元数据错误悄悄积累。6. 长期运行后的几个隐蔽坑碎片、TRIM 与备份方式6.1 qcow2 碎片化问题与整理思路很多人以为虚拟磁盘碎片只存在于客户机内部这是误区。KVM 镜像文件在宿主机文件系统上同样会产生碎片qcow2 尤其明显。因为它按需分配数据块虚拟机长时间频繁写入、删除、再写入qcow2 内部的数据块就会散落在文件各处L2 表里记录的映射变得零碎。结果是顺序读性能明显下降随机写延迟进一步放大。判断 qcow2 碎片化程度可以看qemu-img map输出的映射记录条数。如果一块 100G 的虚拟盘映射记录超过几万条说明碎片情况已经比较严重。整理最直接的办法是离线转换把 qcow2 转换成一个新的 qcow2转换过程中新文件会重新整理数据块的布局。有人觉得这招太笨但确实有效。也可以考虑把镜像迁移到支持更高效分配的文件系统上比如 XFS它的延迟分配策略对 qcow2 这类大文件的碎片控制比 ext4 好。raw 格式在宿主机文件系统上同样会碎片化但它的逻辑地址和文件偏移一般是线性对应的碎片主要来自文件系统的磁盘块分配没有 qcow2 那层映射表的额外放大效果。所以 raw 的性能退化通常比 qcow2 慢但这不代表你可以完全不管。如果宿主机怀疑镜像碎片影响虚拟机 IO可以用e4defrag或 xfs 的在线整理工具去整理镜像文件对应的大文件不过我更建议直接冷备份恢复一次效果来得更彻底。6.2 TRIM/丢弃操作在两种格式下的表现现代操作系统卸载文件时给底层设备发 TRIM 命令告诉 SSD “这块地址的数据可以清了”。在 KVM 里这个命令是否能传递到镜像文件取决于虚拟机磁盘是否开启了 discard 选项。virsh edit里对应的是driver nameqemu typeqcow2 discardunmap/。对 qcow2 来说开启 discard 后虚拟机删除文件释放的空间会被宿主机感知qemu 就会把这些块在 L2 表里标记为未分配镜像文件体积随之缩小。这是 qcow2 长期运行后控制磁盘占用的关键机制。很多运维发现 qcow2 镜像越跑越大删了虚拟机内部几十 G 文件体积纹丝不动就是因为没开启 discard或者虚拟机里没做定期fstrim。raw 格式开不开 discard 情况不一样。如果你的 raw 文件是预分配的TRIM 只会把块标记为“可用”文件体积不会缩小因为它本来就已经固定大小。如果你用的是稀疏 raw 文件TRIM 可以让文件系统释放空洞空间体积实际缩小。不过这里有个隐藏条件宿主机文件系统必须真的支持 punch hole 并把空间归还给文件系统否则 discard 只是个摆设。我的经验是XFS 在这块支持得比 ext4 更干脆用稀疏 raw 配合定期 discard 是可以实现的但千万别以为 raw 预分配也能瘦身。6.3 备份镜像时的误区直接拷贝活体镜像有多危险必须先说一个最常见的错误操作虚拟机还在运行就直接用cp把 qcow2 或 raw 文件复制走当作备份。KVM 虚拟机运行时客户机文件系统不是静止状态直接复制出来的镜像内部很可能存在文件系统不一致系统日志里会有大量 block error严重点甚至导致虚拟机无法启动。rcp、scp、rsync 都一样不解决“一致性”这个核心问题。安全的备份路径有三条。一是先virsh snapshot-create-as snapshot-name --disk-only做一个外部磁盘快照然后备份这个一致性的快照文件。二是用virsh blockbackup配合底层存储系统的快照能力做在线备份这个方案接近零中断但配置复杂一点。三是直接把虚拟机关机再复制镜像文件最保守但最可靠。我个人的习惯是核心虚拟机使用底层存储快照LVM 快照备份普通虚拟机用外部 qcow2 快照备份。还有个小细节备份 qcow2 时如果你想归档建议顺手跑一遍qemu-img check如果提示有泄漏簇或非零引用先用qemu-img check -r leaks修一遍再归档。raw 备份则建议直接按位复制也就是用dd if/dev/... of... bs4M或等价工具尽量避免用 cp因为 cp 对稀疏大文件的处理有时并不理想。6.4 监控与体检日常该盯哪些指标镜像格式选完之后运维不是一劳永逸的。我建议每台宿主机都建一个定时任务定期记录每个虚拟机的镜像文件大小、实际占用du、IO 延迟指标并监控宿主机分区的剩余空间。qcow2 环境里尤其要注意“文件大小剧烈增长”的告警这往往意味着虚拟机的 fstrim 失效了或者有大范围写入放大。对 qcow2 做定期体检的命令是qemu-img check它会校验镜像内部的数据块引用和 L2 表结构。发现错误先分清是leaks还是corruptions。leaks属于“有块没被引用”可以用-r leaks修复corruptions属于“内部结构被破坏”建议先从备份恢复别轻易尝试自动修复。raw 格式的体检更多依赖文件系统工具。fsck在宿主机文件系统层面确认镜像文件所在分区没有错误filefrag可以查看镜像文件的碎片情况。如果底层用 LVM还要定期检查 LV 的剩余空间因为 raw 预分配后空间是固定占用的LV 满了并不会自动扩容。最后再说一句两种格式较量了好多年至今没有绝对胜者。qcow2 用一点性能换来了空间效率和多快照能力raw 用空间换来了简单和低延迟。我在实际运维中的默认策略是空间紧张、测试频繁、需要弹性管理的环境一律 qcow2快照和克隆带来的效率提升远大于那点性能损耗生产环境的核心数据库、高 IO 负载则老老实实用 raw 配合 LVM别为了省那几十 G 空间去和延迟较劲。无论选哪种记得把 fstrim、qemu-img check、定期备份这三件事纳入日常巡检格式本身不会让运维省心好的习惯才会。 
长河君 · 2026/10/16 6:12:06 · 阅读 1.2k KVM虚拟磁盘格式选型：qcow2与raw性能、快照与适用场景全解析
1. 一场磁盘告警引发的思考qcow2 与 raw 到底差在哪1.1 从一次“文件比磁盘还小”的诡异现象说起先说个真实经历。某天凌晨一套 KVM 环境的宿主机报警说/var/lib/libvirt/images分区使用率到了 91%我登录上去一看里面躺着十几个虚拟机的磁盘镜像文件。其中有一台数据库虚拟机的镜像文件大小只有 20G 出头但虚拟机的df -h显示根分区已经用了 78G。合着这个虚拟机的数据量已经远超镜像文件本身的大小了当时第一反应是监控脚本写错了后来才反应过来——这台虚拟机的磁盘格式是 qcow2属于稀疏文件镜像文件的大小不表示虚拟机实际占用的物理空间也不表示它给客户机暴露的逻辑磁盘大小。从那次之后我就把 KVM 环境里两种主流磁盘格式 qcow2 和 raw 的基本特性、适用场景、性能差异彻底梳理了一遍。很多刚接触虚拟化的朋友会把“虚拟磁盘格式”和“磁盘镜像文件大小”搞混。简单说qcow2 是 QEMU 的写时分配格式它只占实际写入数据需要的空间raw 则是一个裸的块设备镜像或者说它就是直接把一块磁盘的所有扇区按顺序复制成一个文件。raw 格式因为缺少元数据层读写路径更短但它的文件大小通常等于虚拟磁盘容量除非你用特殊方式创建稀疏文件。这两种格式在 KVM 环境下是最常被拿来对比的没有绝对的好与坏只有适不适合你的业务场景。1.2 两个词说清分配机制按需取用 vs 一口吃下要理解 qcow2 和 raw 的本质区别先记住两个关键概念按需分配和预分配。qcow2 默认是“按需分配”也就是 thin provisioning。虚拟机只写了一个 1G 的文件qcow2 镜像文件在宿主机上就只占 1G 左右还要算上一点元数据开销。虚拟机不断写数据镜像文件才不断变大。这种机制可以极大节省宿主机存储空间尤其适合那种“创建了很多虚拟机但实际写入量都不大”的环境。它的内部结构分了三层有 header、L1 表、L2 表数据块是按需分配的写数据时要先查映射表找到对应位置如果位置不存在就分配新块再写入。raw 格式就简单直接得多。它本身没有快照、没有元数据、没有压缩就是一块裸盘。如果你用qemu-img create -f raw disk.raw 100G创建镜像文件会立刻占满 100G取决于宿主文件系统因为 raw 格式默认是预分配。但这里有个容易忽略的细节你完全可以用truncate -s 100G disk.raw或qemu-img create -f raw -o preallocationoff disk.raw 100G创建一个所谓的“稀疏 raw 文件”文件看起来有 100G实际占用只有几K后面用到哪块才分配哪块。所以从存储分配的角度看qcow2 天生是稀疏的raw 则可疏可密。但如果你把 raw 做成稀疏文件它的“稀疏”是宿主文件系统比如 ext4、xfs帮你实现的不是 raw 格式自己的特性。换句话说qcow2 的分配管理是自带的raw 的分配管理是借别人的。对比维度qcow2raw预分配raw稀疏文件创建时占用空间极小约 200K 起等于虚拟磁盘大小极小写入时空间增长自动按需增长不增长已全部分配由文件系统按需分配元数据开销有L1/L2 表无无该格式是否自带稀疏能力自带不依赖文件系统依赖文件系统支持qcow2 的按需分配虽然省空间但也带来一个天然问题写入路径变长了。物理服务器上跑数据库、跑高频随机 IO 的场景如果空间不紧张很多人宁愿用 raw 省掉那层映射开销。而如果你的环境是开发测试、云计算平台的多租户虚拟化qcow2 的节省空间能力就非常值钱。这就要看性能和便利性怎么权衡了。2. 性能对比实测同样跑业务差距藏在元数据和快照里2.1 顺序读写与随机 IO 的表现差异很多人一上来就问我“qcow2 性能是不是比 raw 差很多”我的回答是看场景看负载看后端存储。纯顺序读写的场景比如虚拟机里做磁盘镜像拷贝、批量文件传输raw 确实有优势但没网上说的那么夸张。qcow2 在读路径上需要先读 L1/L2 表找到数据块位置再读实际数据正常情况下这张映射数据不大可以被缓存命中所以顺序读的损耗可能只有几个百分点。但在写路径上qcow2 遇到新分配的块要额外执行一次元数据更新顺序写的性能差距会明显一点。随机 IO 的场景差距才会拉开。数据库类负载比如 MySQL、PostgreSQL会产生大量小文件随机读写的 IO。raw 格式下宿主机把请求直接翻译成对镜像文件的偏移量读写路径非常短。qcow2 格式下每次 IO 都要经历“虚拟机发出请求 - 找到对应的 L2 表项 - 确认数据块位置 - 读写实际数据”的过程。如果 L2 表不在缓存里就会多一次甚至几次磁盘寻道随机读写性能就会掉下来。我用fio在同样一台宿主机上做过一轮简单测试后端都是同一块企业级 SSD虚拟机里都跑 CentOS一个用 qcow2一个用 raw。结果大致是这样的不同硬件会有偏差只作参考测试项qcow2raw差距说明顺序读128K 队列深度 16约 1200 MB/s约 1500 MB/sraw 高约 25%元数据查询拖了后腿顺序写128K 队列深度 16约 850 MB/s约 1100 MB/sraw 高约 30%新块分配开销明显随机读4K 队列深度 32约 120K IOPS约 140K IOPSraw 高约 17%缓存命中后差距缩小随机写4K 队列深度 32约 45K IOPS约 80K IOPSraw 高将近一倍qcow2 写入放大严重随机写差距大是因为 qcow2 本身存在“写时分配”的额外消耗。每当写入一个数据块如果该块之前是未分配的先要分配一个新块再把数据写进去同时更新 L2 表。如果频繁覆盖已有块还要处理块引用计数。这些元数据操作叠加在用户 IO 之上就形成了写入放大。而 raw 格式没这些步骤数据写到哪里就是哪里。2.2 快照机制如何悄悄拖慢写入qcow2 的一大卖点就是支持快照但快照也是它性能下降的常见原因。默认情况下你在 KVM 里用virsh snapshot-create-as给 qcow2 虚拟机拍快照QEMU 会把新数据写入一个新的镜像分支原来的数据块变成只读。这样设计的好处是快照点之前的镜像文件保持原样可以随时回退。问题在于如果你在快照之上持续运行业务一旦有写操作落在那些“快照前已经分配并被读入缓存”的块上虚拟机就需要读取旧数据copy-on-write 的 read-modify-write再写入新数据。这一读一写IO 延迟就上去了。我见过一个开发环境qcow2 虚拟机挂着三个快照长期不合并每次提交代码触发一次全量刷新那个虚拟机的磁盘响应时间能从 5 毫秒飙到 300 多毫秒。后来我把快照合并完性能立刻恢复了。raw 格式本身不支持快照但你可以借助后端方案实现类似能力。最常用的思路是底层使用 LVM 卷给每个虚拟机分配一个 LV然后用lvcreate -s做 LVM 快照。LVM 快照和 qcow2 快照不一样它的 COW 机制由内核的 Device Mapper 实现性能损耗比 qcow2 自带的快照小而且不光是磁盘格式层面的功能整个文件系统都能被一致地快照。缺点是要预先规划 VG 空间快照卷也要预留容量。如果你需要频繁快照、回退、保存某个时刻的磁盘状态qcow2 的整合程度最高。但如果你更在意长时间稳定性能那就要谨慎使用快照。要么不用要么用后及时合并别留下一堆“性能债务”。2.3 缓存策略cache 模式与格式的配合既然说到性能就绕不开 KVM 的缓存策略。很多人把缓存策略和磁盘格式混在一起对比其实这俩是不同层面的东西。cachewriteback、cachenone这些是 QEMU 层面控制 “宿主机页缓存如何处理磁盘 IO” 的参数不会改变 qcow2 或 raw 的元数据结构但会影响最终性能表现。我的经验是在 Linux 宿主机上如果你用的是 raw 格式的镜像且把它放在 SSD 上那cachenone加上ionative是比较稳的组合。这样 QEMU 会绕过自身的页缓存直接使用 AIO 原生接口发 IO对数据库这类有自己缓存机制的应用最友好避免了双缓存导致的资源浪费。qcow2 格式则稍微保守一点建议用cachewriteback因为 qcow2 的元数据更新比较频繁让宿主机页缓存帮忙兜着能降低一些 IO 波动。缓存模式raw 下表现qcow2 下表现适用场景writeback性能好但断电有丢数据风险推荐元数据更新更平滑开发测试、可接受掉电不完全一致的场景none native推荐路径最短性能透明可用但 qcow2 映射表 miss 时会放大延迟生产数据库、高随机 IOunsafe性能最强数据安全最差性能提升明显但不建议临时跑批可随时重置我并不建议你把缓存参数照抄到一个生产环境里因为宿主机的 RAID 卡缓存、BBU、存储网络带宽都会干涉最终效果。调优的正确姿势是固定磁盘格式分别测不同 cache 模式记录 P95 延迟和 IOPS再根据业务类型做决定。3. 选型决策表开发机、生产库、临时测试到底该用谁3.1 选型维度拆解空间、性能、运维复杂度抛开纸面参数选格式前先问自己三个问题宿主机存储够不够虚拟机 IO 压力有多大团队对快照、备份等运维能力要求多高第一个是空间问题。如果你在物理机上开 20 台虚拟机每台逻辑盘都开了 100G但实际平均只用了 30G那 qcow2 明显划算总占用可能只需要 600G 左右如果全用预分配的 raw直接就是 2000G 没了。很多虚拟化集群愿意上 qcow2就是因为它能显著提高存储利用率。第二个是性能问题。数据库、重负载应用尤其是有大量随机写的小虚拟机raw 的后端写放大更小长期运行更稳。第三个是运维复杂度。qcow2 的快照、克隆、压缩、加密都是命令行内建能力raw 想有类似功能得借助 LVM、zfs、btrfs 这些宿主文件系统对团队的技术栈要求更高。还有一点常常被忽略虚拟磁盘格式和宿主机文件系统的耦合度。raw 格式存放在任意文件系统上性能很大程度取决于文件系统的分配策略qcow2 则多了一层自己的块管理。如果宿主机用 XFS、ext4两种格式都能跑。如果底层是 ZFS那 raw 配合 ZFS 的块引用快照反而能获得比 qcow2 更好的数据管理体验这时不一定非要选 qcow2。3.2 给不同场景的推荐组合基于这些维度我一般给不同场景开不同的“处方”。开发测试环境首选 qcow2。空间利用率高快照回退方便配合qemu-img create -b基础镜像还能实现秒级创建开发机。一个 20G 的基础镜像后面挂 8 台开发机每台只占几百 M 的差异数据量。测试人员随便改系统、随便折腾出了问题恢复快照就行成本极低。生产数据库虚拟机我通常推荐 raw 预分配同时配合 LVM。数据库需要稳定的 IOPS 和低延迟raw 格式少了一层元数据转换更符合“稳定压倒一切”的原则。用 LVM 做底层卷管理可以在线扩展虚拟机磁盘还支持 LVM 快照是生产环境里比较扎实的组合。不过 raw 注意保持一定的宿主机存储余量因为文件创建后立即占满。CI 机器人 / 临时测试机如果你有一个 KVM 集群在跑 CI比如每次代码提交都拉起几台虚拟机跑集成测试跑完就销毁那 qcow2 还是最优解。你可以准备一个“干净系统”的基础镜像多个临时虚拟机用同一个 base 镜像创建销毁时只删除差异盘宿主机空间压力很小。如果再配一个zstd压缩的 qcow2 镜像作为镜像仓库创建虚拟机的速度会更快。网盘、对象存储网关这类 IO 慢但空间大的应用这种应用一般是“大带宽顺序读写但延迟不敏感”raw 和 qcow2 都能胜任。这里更该关注的是底层存储介质和网络而不是格式。我觉得别为了追求性能盲目上 raw毕竟 qcow2 的压缩特性在这种场景下能省不少空间。下面这张表总结一下我的推荐场景推荐格式理由开发测试机qcow2省空间快照方便克隆快生产数据库raw LVM低延迟无元数据开销快照够用CI 临时实例qcow2 backing file秒级创建空间占用极低长期归档镜像qcow2 压缩减小镜像体积完整保留虚拟盘状态大容量文件服务器raw 或 qcow2 均可瓶颈在存储介质格式影响小4. qcow2 独有的高级特性快照、压缩、加密与后备盘4.1 内置快照与外部快照的区别既然聊 qcow2就必须把它最拿得出手的几项高级能力说清楚。前面提到的快照细分下来有两种玩法内置快照internal snapshot和外部快照external snapshot。内置快照是把快照状态直接保存在同一个 qcow2 文件里用virsh snapshot-create-as --disk-only或者qemu-img snapshot -c创建。它的好处是管理简单一个镜像文件自带多个历史状态回退时用virsh snapshot-revert一条命令搞定。缺点是文件会变得越来越大因为旧数据块不能被回收快照多了之后虚拟机的写性能明显下降。外部快照就灵活多了。创建时 QEMU 会生成一个新的 qcow2 文件作为当前活跃层原来的 qcow2 变成只读的基础层。你可以一层一层叠形成一个快照链。这种设计非常契合“想随时回到某个历史状态、又不想让单一文件膨胀失控”的场景。运维上要用virsh blockcommit把上面层的数据合并回底层或者用virsh blockpull把底层合并到顶层操作链条不复杂但概念容易绕新手经常分不清 commit 和 pull 的方向。内部快照链不会污染镜像文件之外的东西但生产环境我更倾向外部快照因为合并失败还能用底层文件单独恢复到某个时点。我这套习惯是在一次“内部快照把文件撑到 300Gqemu-img check 还报了多处不一致”的教训之后形成的。4.2 压缩与加密对性能的实际影响qcow2 支持-o compressionon可以用qemu-img convert -c把现有镜像重新转换成压缩格式。压缩带来的空间收益非常可观尤其是安装好系统、清理完缓存后的基准镜像体积可能减少一半。代价是 CPU 需要在读写时进行压缩/解压操作所以压缩镜像的 IO 延迟会比不压缩的略高CPU 占用也更高。我在一台只有 4 核的宿主机上做过测试5 台压缩 qcow2 虚拟机同时跑编译任务整体耗时比不压缩多出约 15%-20%但空间节省了 40% 以上。空间紧张、CPU 繁忙程度不高的环境压缩是收益大于代价的。加密这块qcow2 支持 AES 加密创建时指定-o encrypt.formatluks就能给磁盘镜像加上一层保护。它的原理是给虚拟磁盘的数据块加密没有密钥就无法读取镜像内容。这对移动介质上的虚拟机、外包运维场景很有用。但加密的代价不只是性能还有密钥管理的复杂度。如果你忘了密码那整块虚拟盘的数据基本等于没了系统层面的文件恢复工具再好都救不回来。所以我不建议在性能敏感环境里开加密如果确实有合规需求不如走系统层面加密或者用宿主机文件系统的加密能力。4.3 backing file 的继承链玩法这是 qcow2 比 raw 灵活得多的一块。用qemu-img create -f qcow2 -b base.qcow2 -F qcow2 child.qcow2创建带后备文件backing file的镜像子镜像只记录与基础镜像的差异数据。这种设计经常被用来做“黄金镜像 差异磁盘”的分层体系。实际管理上我建议遵循两个原则第一基础镜像必须是完全干净且相对固定的版本不打补丁、不装多余软件。第二子镜像生命周期结束后要及时清理避免底层基础镜像改了几百个子镜像的引用关系变得一团乱麻。KVM 不会强制校验子镜像和 base 镜像的匹配关系但如果你误删了 base 文件所有依赖它的子镜像就全废了。在libvirt里带 backing 的 qcow2 通常用于快速生成多台同配置虚拟机比如考试环境里一次给 20 个学员开同样配置的 Linux 实验机。创建时只是创建一个很小的差异文件几秒钟就能把虚拟机定义好等学员开始操作才慢慢分配空间。这正是 qcow2 对比 raw 最大的商业模式级优势——省的不只是容量还有创建时间。5. 转换与迁移实操从 qcow2 到 raw 的完整流程复盘5.1 qemu-img convert 的核心参数与目标大小预估没人能保证一种格式用一辈子。很多时候开发环境里用 qcow2 写满了一堆数据要搬到生产环境做数据库就得把它转成 raw。这时候核心工具就是qemu-img convert。转格式前先做两个准备第一虚拟机最好关机或者至少确保文件系统是静态一致状态。我在运行中转过一次结果客户机文件系统里出现了少量不一致虽然fsck能修但没必要冒这个险。第二用qemu-img info source.qcow2看当前磁盘的虚拟大小和实际占用这决定了目标 raw 文件要多少空间。比如虚拟磁盘是 100G但 qcow2 实际只占了 30G转成 raw 后目标文件在预分配模式下就是 100G如果宿主机空间不够 100G你就得先用truncate建一个稀疏 raw转换完成后看du -h确认实际占用。标准的转换命令是这样# 查看源镜像信息 qemu-img info source.qcow2 # 转换为 raw-p 显示进度-f 指源格式-O 指目标格式 qemu-img convert -p -f qcow2 -O raw source.qcow2 dest.raw转换过程本质上是按“虚拟磁盘布局”逐块复制数据目标文件大小等于虚拟磁盘的容量而不是源镜像的实际占用。所以如果你空间紧张最好先把源镜像里的空闲空间清理掉。Linux 虚拟机可以用fstrim或virt-sparsify工具瘦身Windows 虚拟机需要在系统里执行“优化驱动器”里的 TRIM 操作。瘦身后再转换目标 raw 的实际占用会小很多。另外qemu-img convert也支持直接加压缩选项比如# 把 raw 转成 qcow2 并压缩 qemu-img convert -p -f raw -O qcow2 -c source.raw dest.qcow2如果你转换的目的是为了归档备份压缩选项就很值。如果是为了继续跑生产负载我一般不加-c避免无谓的 CPU 开销。5.2 转换过程中最容易踩的三个坑第一个坑是“目标文件被占用了却不知道”。我在一次在线迁移时目标虚拟机还没关机又顺手执行了向目标路径写入的 convert 命令结果目标文件被 QEMU 进程锁定convert 直接报错。正确流程是先virsh shutdown关闭虚拟机确保镜像文件不再被进程占用再开始转换。第二个坑是“引导方式不匹配”。qcow2 和 raw 本身不涉及引导差异但有些老系统在安装时生成的/boot/grub2/grub.cfg里root 设备用的是设备 ID 或/dev/vda转换完镜像挂到一个不同的 virtio 设备编号上就可能出现 kernel panic。遇到这种情况不要急着怀疑转换失败先用virt-rescue或手动挂载目标镜像检查/etc/fstab和 grub 配置修正设备路径后再启动。现在的发行版大多用 UUID 定位根分区这个问题已经少多了但老镜像还是能碰上。第三个坑是“空间判错转换到一半磁盘写满”。比如虚拟磁盘 200G宿主机空闲只剩 180G你硬转 raw跑到 90% 就报No space left on device目标文件直接损坏。我的习惯是先qemu-img convert到一个同分区的临时路径等完成并校验后再mv到最终位置。虽然多一次拷贝但至少不会破坏原有镜像。同时转换前用df -h确认目标分区至少得有“虚拟磁盘容量 10%”的余量。5.3 就地转换的思路临时盘加重启方案如果你不想把虚拟机关太久可以采用“临时盘就地转换”的方式。大概流程是这样在宿主机上新分配一块容量足够的存储空间把 qcow2 转换成 raw 写到临时路径然后直接修改虚拟机的 libvirt XML 定义把磁盘路径指向新的 raw 文件最后启动虚拟机验证业务。验证没问题再删除旧镜像。这套方案的关键点是新 raw 文件必须与原虚拟机的磁盘总线类型、设备名保持一致否则客户机里的/dev/sda可能变成/dev/sdb。如果用的是 SATA 或 virtio-blk通常不改也没事但我还是建议在 XML 里保持原样避免节外生枝。另一个就地转换的例外技巧如果你只是想从 qcow2 换成 raw 以获得更低延迟但虚拟机已经承载了核心业务不好中断那就先做一次文件系统层面的快照比如 LVM 快照然后把快照转成 raw再把业务切过去。这种方式停机时间可以控制在几分钟内前提是网络、存储规划得当。5.4 反向迁移什么时候该从 raw 转回 qcow2反向转换的需求一点都不少。我遇到最多的是这两个理由一是想把生产环境的一台 raw 虚拟机变成开发测试机需要精简单机并引来快照能力二是宿主机规划存储空间后发现 raw 太占地方全部转成 qcow2 能做到空间减半。命令几乎没有差别只是把源格式和目标格式反过来qemu-img convert -p -f raw -O qcow2 source.raw dest.qcow2从 raw 转 qcow2最大的好处是转完之后文件体积会立刻变小因为 qcow2 会按实际占用分配块。但有个点要注意qcow2 默认不做空洞识别如果你在 raw 里删了很多大文件转换时这些空闲块也会被当成普通数据写进目标文件。先对客户机执行fstrim再转换效果会好很多。还有转成 qcow2 之后如果你计划长期依赖快照务必定期qemu-img check检查一致性别让元数据错误悄悄积累。6. 长期运行后的几个隐蔽坑碎片、TRIM 与备份方式6.1 qcow2 碎片化问题与整理思路很多人以为虚拟磁盘碎片只存在于客户机内部这是误区。KVM 镜像文件在宿主机文件系统上同样会产生碎片qcow2 尤其明显。因为它按需分配数据块虚拟机长时间频繁写入、删除、再写入qcow2 内部的数据块就会散落在文件各处L2 表里记录的映射变得零碎。结果是顺序读性能明显下降随机写延迟进一步放大。判断 qcow2 碎片化程度可以看qemu-img map输出的映射记录条数。如果一块 100G 的虚拟盘映射记录超过几万条说明碎片情况已经比较严重。整理最直接的办法是离线转换把 qcow2 转换成一个新的 qcow2转换过程中新文件会重新整理数据块的布局。有人觉得这招太笨但确实有效。也可以考虑把镜像迁移到支持更高效分配的文件系统上比如 XFS它的延迟分配策略对 qcow2 这类大文件的碎片控制比 ext4 好。raw 格式在宿主机文件系统上同样会碎片化但它的逻辑地址和文件偏移一般是线性对应的碎片主要来自文件系统的磁盘块分配没有 qcow2 那层映射表的额外放大效果。所以 raw 的性能退化通常比 qcow2 慢但这不代表你可以完全不管。如果宿主机怀疑镜像碎片影响虚拟机 IO可以用e4defrag或 xfs 的在线整理工具去整理镜像文件对应的大文件不过我更建议直接冷备份恢复一次效果来得更彻底。6.2 TRIM/丢弃操作在两种格式下的表现现代操作系统卸载文件时给底层设备发 TRIM 命令告诉 SSD “这块地址的数据可以清了”。在 KVM 里这个命令是否能传递到镜像文件取决于虚拟机磁盘是否开启了 discard 选项。virsh edit里对应的是driver nameqemu typeqcow2 discardunmap/。对 qcow2 来说开启 discard 后虚拟机删除文件释放的空间会被宿主机感知qemu 就会把这些块在 L2 表里标记为未分配镜像文件体积随之缩小。这是 qcow2 长期运行后控制磁盘占用的关键机制。很多运维发现 qcow2 镜像越跑越大删了虚拟机内部几十 G 文件体积纹丝不动就是因为没开启 discard或者虚拟机里没做定期fstrim。raw 格式开不开 discard 情况不一样。如果你的 raw 文件是预分配的TRIM 只会把块标记为“可用”文件体积不会缩小因为它本来就已经固定大小。如果你用的是稀疏 raw 文件TRIM 可以让文件系统释放空洞空间体积实际缩小。不过这里有个隐藏条件宿主机文件系统必须真的支持 punch hole 并把空间归还给文件系统否则 discard 只是个摆设。我的经验是XFS 在这块支持得比 ext4 更干脆用稀疏 raw 配合定期 discard 是可以实现的但千万别以为 raw 预分配也能瘦身。6.3 备份镜像时的误区直接拷贝活体镜像有多危险必须先说一个最常见的错误操作虚拟机还在运行就直接用cp把 qcow2 或 raw 文件复制走当作备份。KVM 虚拟机运行时客户机文件系统不是静止状态直接复制出来的镜像内部很可能存在文件系统不一致系统日志里会有大量 block error严重点甚至导致虚拟机无法启动。rcp、scp、rsync 都一样不解决“一致性”这个核心问题。安全的备份路径有三条。一是先virsh snapshot-create-as snapshot-name --disk-only做一个外部磁盘快照然后备份这个一致性的快照文件。二是用virsh blockbackup配合底层存储系统的快照能力做在线备份这个方案接近零中断但配置复杂一点。三是直接把虚拟机关机再复制镜像文件最保守但最可靠。我个人的习惯是核心虚拟机使用底层存储快照LVM 快照备份普通虚拟机用外部 qcow2 快照备份。还有个小细节备份 qcow2 时如果你想归档建议顺手跑一遍qemu-img check如果提示有泄漏簇或非零引用先用qemu-img check -r leaks修一遍再归档。raw 备份则建议直接按位复制也就是用dd if/dev/... of... bs4M或等价工具尽量避免用 cp因为 cp 对稀疏大文件的处理有时并不理想。6.4 监控与体检日常该盯哪些指标镜像格式选完之后运维不是一劳永逸的。我建议每台宿主机都建一个定时任务定期记录每个虚拟机的镜像文件大小、实际占用du、IO 延迟指标并监控宿主机分区的剩余空间。qcow2 环境里尤其要注意“文件大小剧烈增长”的告警这往往意味着虚拟机的 fstrim 失效了或者有大范围写入放大。对 qcow2 做定期体检的命令是qemu-img check它会校验镜像内部的数据块引用和 L2 表结构。发现错误先分清是leaks还是corruptions。leaks属于“有块没被引用”可以用-r leaks修复corruptions属于“内部结构被破坏”建议先从备份恢复别轻易尝试自动修复。raw 格式的体检更多依赖文件系统工具。fsck在宿主机文件系统层面确认镜像文件所在分区没有错误filefrag可以查看镜像文件的碎片情况。如果底层用 LVM还要定期检查 LV 的剩余空间因为 raw 预分配后空间是固定占用的LV 满了并不会自动扩容。最后再说一句两种格式较量了好多年至今没有绝对胜者。qcow2 用一点性能换来了空间效率和多快照能力raw 用空间换来了简单和低延迟。我在实际运维中的默认策略是空间紧张、测试频繁、需要弹性管理的环境一律 qcow2快照和克隆带来的效率提升远大于那点性能损耗生产环境的核心数据库、高 IO 负载则老老实实用 raw 配合 LVM别为了省那几十 G 空间去和延迟较劲。无论选哪种记得把 fstrim、qemu-img check、定期备份这三件事纳入日常巡检格式本身不会让运维省心好的习惯才会。