Raw vs QCOW2 镜像：如何选择虚拟磁盘格式？

在 KVM 或 QEMU 中部署虚拟机时，虚拟磁盘格式的选择很早就需要做出决定，通常需要在 raw 和 QCOW2 之间二选一——也就是常说的 raw vs qcow2 。两者都支持相同的客户机操作系统，但 raw 优先考虑 I/O 性能，而 QCOW2 以少量开销换取快照、精简置备和压缩等功能。您选择的格式会影响 VM 性能、磁盘空间使用、备份工作流和日常管理。本指南详细解析两者差异，帮助您为工作负载选择正确的格式。

您选择的格式会影响 VM 性能、磁盘空间使用、备份工作流和日常管理。本指南详细解析两者差异，帮助您为工作负载选择正确的格式。

什么是 Raw 和 QCOW2 磁盘镜像？

要在两种格式之间做出选择，了解每种格式如何在主机上存储和管理虚拟磁盘数据会有所帮助。

什么是 Raw 磁盘镜像

Raw 磁盘镜像是 KVM/QEMU 中最简单的虚拟磁盘格式。它按扇区逐字存储虚拟磁盘的内容，没有附加结构或元数据层。

Raw 镜像的工作原理

Raw 镜像将虚拟磁盘块直接映射到主机存储。没有内部元数据、没有块索引、也没有快照表。当 VM 写入数据时，Hypervisor 将其直接传递到磁盘上的对应位置，这就是 raw 镜像能够提供接近原生的 I/O 性能的原因。

稀疏文件行为

Raw 镜像并不总是完全分配的。当创建为稀疏文件时，镜像仅在客户机写入数据时消耗物理空间。一个 100 GB 的稀疏 raw 镜像在全新安装操作系统后可能仅占用 5 GB。

需要注意的一点是：一些复制工具在迁移过程中会用实际数据填充空块，导致镜像在目标端扩展到其完整虚拟大小。

什么是 QCOW2 磁盘镜像

QCOW2（QEMU Copy-On-Write version 2）是 QEMU 的原生磁盘镜像格式。与 raw 不同，它以少量性能开销为代价，换取了内置的快照、精简置备、压缩、加密和后端文件支持。

写时复制架构与集群分配

QCOW2 将数据组织为 64 KB 集群，并且仅在客户机写入集群时才分配物理存储。这意味着镜像按需增长，而不是预先占用其完整置备容量。

后端文件的工作方式相同：QCOW2 仅记录相对于基础镜像的变更，原始镜像保持不变。这使其成为 VM 模板和链接克隆的标准选择。

L1/L2 表查找机制

QCOW2 使用两级索引——一个 L1 表指向 L2 表，L2 表再映射到实际数据集群。每次读取或写入都需要先遍历此索引才能到达数据，与 raw 的直接块映射相比增加了延迟。对于顺序 I/O，影响较小，但在高随机工作负载下更为明显。

Raw vs QCOW2：核心功能对比

两种格式对存储的处理方式不同。raw 保持简单快速；QCOW2 在此基础上增加了功能层。下表总结了主要差异。

存储分配与精简置备

Raw 镜像可以创建为稀疏文件，这在文件系统层面提供了基本的精简置备功能。缺点在于，稀疏行为依赖于主机文件系统和所使用的工具——某些复制或备份工具会在传输过程中用实际数据填充空块，导致镜像膨胀到其完整虚拟大小。

QCOW2 在镜像层面处理精简置备。QEMU 直接管理集群分配，因此无论使用哪种主机文件系统或传输工具，镜像都会按需增长。

快照支持与后端文件链

Raw 镜像没有内置快照支持。基于 raw 的 VM 的快照依赖于外部机制，如 LVM 快照、Ceph 快照或存储阵列功能。

QCOW2 原生支持内部和外部快照，并支持后端文件。多个 VM 可以共享一个只读的基础镜像，并将各自的变更存储在单独的覆盖文件中，这可以在大规模部署中显著减少存储使用。

压缩与加密

Raw 没有原生压缩或加密功能。这些需要在主机文件系统、存储平台或客户机操作系统层面处理。

QCOW2 支持 LUKS 加密以及通过 zlib 或 zstd 进行的压缩。两者在归档 VM 模板或维护黄金镜像时都非常有用，存储效率是关键考量。

在线迁移与在线扩容

在具备适当的共享存储或迁移基础设施的情况下，两种格式都支持 KVM 主机之间的在线迁移。Raw 在迁移开销方面可能有轻微优势，因为它不携带元数据，但在实际中差异很小，网络带宽通常是瓶颈。

对于在线扩容，两种格式都支持在 VM 运行时扩展虚拟磁盘。QCOW2 自动更新其元数据；raw 依赖底层存储和客户机工具来识别新增空间。

Raw vs QCOW2：性能对比

性能是在 raw 和 QCOW2 之间选择时最常见的考量因素之一。Raw 具有结构优势，因为它提供了更简单的存储路径，但实际性能差异在很大程度上取决于工作负载、存储后端和配置。

性能差距有多大？

在预分配存储上的顺序工作负载下，raw 和 QCOW2 之间的性能差异通常很小。两种格式在读取密集型工作负载或中等 I/O 需求环境中都能提供相似的吞吐量。

在以下场景下，差距变得更加明显：

• 高随机写入工作负载
• 深度 QCOW2 快照链
• 高度碎片化的 QCOW2 镜像
• 较慢的存储后端，如基于 HDD 或网络存储

什么导致了性能差异？

Raw 将虚拟磁盘块直接映射到主机存储，无需中间层，使 I/O 路径尽可能短。QCOW2 在多个环节增加了处理开销：

• 元数据转换。在每次写入之前，QEMU 需要查询 L1 和 L2 表来定位或分配正确的集群。如果集群是新的，元数据表也会在写入过程中更新。
• 碎片化。QCOW2 动态分配集群，因此数据并不总是连续写入。在基于 HDD 的系统上，随着镜像填满，寻道开销会增加。
• 快照链深度。较长的后端文件链要求 QEMU 遍历多个元数据层来定位旧数据块，增加了读取延迟。

在高随机写入工作负载下，这些因素叠加，与 raw 相比延迟差异变得更加明显。

如何改善 QCOW2 性能

如果您需要 QCOW2 的功能，但又希望缩小与 raw 的性能差距，以下 QEMU 调优选项可以提供帮助：

• 预分配 （preallocation=metadata 或 preallocation=falloc）：通过在镜像创建时准备元数据结构或分配存储空间，减少运行时分配开销。
• 缓存模式 （cache=none）：绕过主机页缓存，避免客户机和主机之间的双重缓存。在某些基于 SSD 的环境中，cache=writeback 可以通过合并写操作来提高吞吐量。
• 异步 I/O （aio=native 或 aio=io_uring）：允许 QEMU 以更高效的方式处理 I/O 请求，减少内核开销。
• L2 缓存大小 （l2-cache-size）：在内存中保留更多 QCOW2 元数据表，减少地址转换过程中的额外磁盘访问。

差异什么时候真正重要？

Raw 的性能优势在 I/O 密集型工作负载中最为重要，此时存储延迟直接影响应用响应时间。例如高并发事务数据库、繁忙的消息队列和大规模日志处理系统。

对于通用虚拟机、开发环境和测试实验室，性能差异通常很小，QCOW2 的操作优势（快照、精简置备和后端文件）比 raw 的额外性能提供更大的价值。

Raw vs QCOW2：应该选择哪个？

性能只是一个因素。正确的格式取决于您的存储架构、操作工作流、备份策略和工作负载要求。

快速决策指南

选择 Raw，如果您：

• 需要为延迟敏感型工作负载提供最高的 I/O 性能
• 在存储层（SAN、Ceph 或 LVM）管理快照和备份
• 运行事务密集型数据库或其他 I/O 密集型应用
• 希望使用最简单的存储路径，元数据开销最小

选择 QCOW2，如果您：

• 需要内置的 VM 快照功能
• 希望使用精简置备来提高存储效率
• 使用基础镜像或模板来部署多个 VM
• 需要内置加密、压缩或后端文件支持

哪种格式适合您的使用场景？

最佳格式取决于您运行的内容。以下是按常见场景划分的指南。

1. 数据库和高 I/O 工作负载

对于 MySQL、Oracle 或 PostgreSQL 等高并发事务数据库，raw 是更安全的默认选择。如果您的存储层已通过 LVM、Ceph 或 SAN 处理快照，您可以在不放弃快照能力的情况下获得 raw 的性能优势。

2. 通用 VM

QCOW2 在此场景下表现良好。在系统更新前拍摄快照，并在出现问题时回滚，使用 QCOW2 比协调 raw 镜像的存储层快照要简单得多。

3. VM 模板

QCOW2 的后端文件机制允许多个 VM 共享一个基础镜像，每个实例仅存储自己的变更。如果不为每个 VM 复制完整镜像，raw 无法实现这一点。

4. 云平台

大多数云平台（包括 OpenStack）默认期望 QCOW2。使用 raw 可能需要在上传或部署前进行格式转换，增加了工作流的额外步骤。

5. 测试和实验室

能够在无需接触外部存储工具的情况下进行快照、测试和回滚，是 QCOW2 成为实验室环境中标准选择的主要原因。

如何在 Raw 和 QCOW2 之间进行转换

如果您的存储策略或平台要求发生变化，您可以使用 qemu-img（QEMU 标准的虚拟磁盘管理工具）转换现有的磁盘镜像。

qemu-img 转换命令参考

在转换之前关闭 VM，或确保镜像未被主动写入。

将 raw 转换为 QCOW2：

qemu-img convert -f raw -O qcow2 source_image.raw destination_image.qcow2 -p

将 QCOW2 转换为 raw：

qemu-img convert -f qcow2 -O raw source_image.qcow2 destination_image.raw -p

注意，如果目标文件系统不支持稀疏文件，将 QCOW2 转换为 raw 可能会显著增加物理文件大小。

跨平台迁移转换

在 VMware 和 KVM 环境之间迁移时，qemu-img 也可以处理 VMDK 到 QCOW2 的转换。

将 VMDK 转换为 QCOW2：

qemu-img convert -f vmdk -O qcow2 source_disk.vmdk destination_disk.qcow2 -p

将 QCOW2 转换为 VMDK：

qemu-img convert -f qcow2 -O vmdk source_disk.qcow2 destination_disk.vmdk -p

对于 Windows VM，请在转换前安装 VirtIO 驱动程序。否则，VM 在迁移到 KVM 环境后可能无法启动。

转换后验证完整性

在将转换后的镜像挂载到 VM 之前，运行快速检查：

qemu-img info destination_image.qcow2
qemu-img check -f qcow2 destination_image.qcow2

qemu-img info 显示镜像格式、虚拟大小、实际磁盘使用情况和后端文件配置。qemu-img check 验证 QCOW2 元数据并报告泄漏集群或引用计数错误等问题。

如何备份 Raw 和 QCOW2 并拍摄快照

Raw 和 QCOW2 需要不同的备份方法。您选择的格式会影响可用的工具和策略。

备份 Raw 镜像

Raw 镜像没有内置快照支持，因此备份依赖于存储或虚拟化层。对于离线备份，您可以使用 dd 复制已关闭的镜像：

dd if=source_image.raw of=/backup/destination_image.raw bs=1M status=progress

在 VM 运行时复制 raw 镜像存在备份不一致的风险。在生产环境中，使用存储级快照（LVM、Ceph 或 SAN）或虚拟化平台 API 来捕获一致状态，无需停机。

备份 QCOW2 镜像

QCOW2 内置的快照支持提供了更大的灵活性。在生产环境中，外部快照通常优于内部快照，因为它们更易于管理并集成到备份工作流中。

QCOW2 的写时复制架构还支持增量备份：只需捕获自上次快照以来变更的数据，从而减少备份大小和时间。

避免过长的快照链

快照对短期保护有用，但不应替代适当的备份。随着链的增长，QEMU 需要遍历更多的后端文件层来读取数据，这会增加延迟并降低存储性能。在不再需要快照时，定期合并或删除它们。

使用 i2Backup 进行企业级 VM 备份

随着您的 VM 环境增长，手动备份工作流将越来越难以维护。i2Backup 通过使用原生虚拟化平台 API 的 无代理备份 自动化此过程，同时支持基于 raw 和 QCOW2 的 VM。

i2Backup 不使用每次都完整复制镜像的方式，而是使用 块级变更跟踪 仅捕获已变更的数据，从而减少备份窗口和存储消耗。在恢复方面，它支持通过直接挂载备份镜像进行即时 VM 恢复，以及在不恢复整个 VM 的情况下恢复单个文件或文件夹的文件级恢复。

结论

Raw 和 QCOW2 满足不同的需求。Raw 提供更简单的 I/O 路径和在高工作负载下更好的性能。QCOW2 以少量开销换取快照、精简置备和后端文件支持，使日常 VM 管理更加轻松。

对于大多数通用部署，QCOW2 是实用的默认选择。对于像高并发事务数据库这样的延迟敏感型工作负载，raw 值得权衡，特别是当您的存储层已经独立处理快照时。

无论您使用哪种格式，请确保您的备份策略不仅仅依赖快照。快照是有用的检查点，但它们不能替代适当且可恢复的备份。