The QCOW2 Image Format

关注

原创最新推荐文章于 2026-08-11 07:51:10 发布 1.8k 阅读 AI 写同款· GEO 优化 ›

别再纠结了！KVM虚拟化实战：RAW和QCOW2磁盘格式到底怎么选？附qemu-img保姆级操作指南本文深入探讨KVM虚拟化中RAW和QCOW2磁盘格式的选择策略，通过性能对比、适用场景分析和qemu-img操作指南，帮助用户根据实际需求做出最优决策。QCOW2格式支持快照和压缩等高级功能，而RAW格式则提供更接近物理磁盘的性能表现。阅读详情

What's QCOW?

QCOW is stands for "Qemu Copy On Write", it's an image format used by the QEMU,

Two versions exist, qcow and qcow2, which use the qcow and qcow2 as the file extensions respectively.

Features:

compared with the RAW format images , the QCOW2 format has these benefits as below:

1, smaller file size, even though the OS is not support the Hole file(sparse file),

2, support Copy-On-Write,

3, support snap-shot,

4, optional zlib based compression,

5, optional AES encryption .typedef struct

File Header:


/*copy form the Qemu source code
 *directory: qemu/block/qcow2.h
*/

typedef struct QCowHeader {
    uint32_t magic;
    uint32_t version;
    uint64_t backing_file_offset;
    uint32_t backing_file_size;
    uint32_t cluster_bits;
    uint64_t size; /* in bytes */
    uint32_t crypt_method;
    uint32_t l1_size; /* XXX: save number of clusters instead ? */
    uint64_t l1_table_offset;
    uint64_t refcount_table_offset;
    uint32_t refcount_table_clusters;
    uint32_t nb_snapshots;
    uint64_t snapshots_offset;

    /* The following fields are only valid for version >= 3 */
    uint64_t incompatible_features;
    uint64_t compatible_features;
    uint64_t autoclear_features;

    uint32_t refcount_order;
    uint32_t header_length;
} QEMU_PACKED QCowHeader;

The first cluster of a qcow2 image contains the file header:

Byte 0 - 3: magic，QCOW magic string ("QFI\xfb")

4 - 7: version, Version number (valid values are 2 and 3)

8 - 15: backing_file_offset

16 - 19: backing_file_size

20 - 23: cluster_bits

24 - 31: size, Virtual disk size in bytes

          32 - 35:   crypt_method
                                0 for no encryption
                                1 for AES encryption
          36 - 39:   L1_size, Number of entries in the active L1 table
          40 - 47:   L1_table_offset,

Offset into the image file at which the active L1 table starts. Must be aligned to a cluster boundary.

48 - 55: refcount_table_offset

                    Offset into the image file at which the refcount table
                      starts. Must be aligned to a cluster boundary.

          56 - 59:   refcount_table_clusters， Number of clusters that the refcount table occupies

          60 - 63:   nb_snapshots, Number of snapshots contained in the image

          64 - 71:   snapshots_offset, Offset into the image file at which the snapshot table starts. Must be aligned to a cluster boundary.

          If the version is 3 or higher, the header has the following additional fields.

          72 - 79:   incompatible_features
                     Bitmask of incompatible features. An implementation must
                     fail to open an image if an unknown bit is set.

                     Bit 0:      Dirty bit. If this bit is set then refcounts
                                 may be inconsistent, make sure to scan L1/L2
                                 tables to repair refcounts before accessing the
                                 image.

                     Bit 1:      Corrupt bit. If this bit is set then any data
                                 structure may be corrupt and the image must not
                                 be written to (unless for regaining
                               consistency).

                     Bits 2-63: Reserved (set to 0)

         80 - 87: compatible_features
                    Bitmask of compatible features. An implementation can
                    safely ignore any unknown bits that are set.

                    Bit 0:      Lazy refcounts bit. If this bit is set then
                                lazy refcount updates can be used. This means
                                marking the image file dirty and postponing
                                refcount metadata updates.

                    Bits 1-63: Reserved (set to 0)

         88 - 95: autoclear_features
                    Bitmask of auto-clear features. An implementation may only
                    write to an image with unknown auto-clear features if it
                    clears the respective bits from this field first.

                    Bit 0:      Bitmaps extension bit
                                This bit indicates consistency for the bitmaps
                                extension data.

                                It is an error if this bit is set without the
                                bitmaps extension present.

                                If the bitmaps extension is present but this
                                bit is unset, the bitmaps extension data must be
                                considered inconsistent.

                    Bits 1-63: Reserved (set to 0)

         96 - 99: refcount_order
                    Describes the width of a reference count block entry (width
                        in bits: refcount_bits = 1 << refcount_order). For version 2
                    images, the order is always assumed to be 4
                    (i.e. refcount_bits = 16).
                    This value may not exceed 6 (i.e. refcount_bits = 64).

        100 - 103: header_length
                    Length of the header structure in bytes. For version 2
                    images, the length is always assumed to be 72 bytes.

A Sample of Typical Qcow2 File's Header:

0000000: 5146 49fb 0000 0003 0000 0000 0000 0108 QFI.............
    [ magic]     [version]       [backing file offset]
    Q F I 0Xfb             003                              0X108
0000010: 0000 002a 0000 0010 0000 0002 4000 0000 ...*....N....@...
                   [backSize] [clusterBits]    [size/*in bytes*/]
                            0X2A   0X10=16 bits         0X240000000 bytes
0000020: 0000 0000 0000 0012 0000 0000 0003 0000 ................
                  [ctyptMethod]    [LlSize] [ LlTableOffset ]
0000030: 0000 0000 0001 0000 0000 0001 0000 0000 ................
                [ refcountTbOffset ] [refTbClst]     [nbSnapshot]
0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
       [ snapshotOffset ]
0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000060: 0000 0004 0000 0068 6803 f857 0000 0090 .......hh..W....
0000070: 0000 6469 7274 7920 6269 7400 0000 0000 ..dirty bit.....
0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000a0: 0001 636f 7272 7570 7420 6269 7400 0000 ..corrupt bit...
00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000d0: 0100 6c61 7a79 2072 6566 636f 756e 7473 ..lazy refcounts
00000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000100: 0000 0000 0000 0000 2f72 6f6f 742f 7465 ......../root/te
     0X100     0 1    2 3   4 5    6 7 8
     0X107   = 0X108 - 1
0000110: 7374 2f69 6d61 6765 2f69 6133 3265 5f72 st/image/ia32e_r
0000120: 6865 6c37 7532 5f63 7075 3230 3036 2e69 hel7u2_cpu2006.i
0000130: 6d67 0000 0000 0000 0000 0000 0000 0000 mg..............
     0X130       0 1
     0X131 = 0X107 + 0X2A
0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................

now, when we use qemu-img -info to display this image's info, the result as below:

[root@gr-mrb-64 ~]# qemu-img info rhel7_cpu2006.qcow
image: rhel7_cpu2006.qcow
file format: qcow2
virtual size: 9.0G (9663676416 bytes)
disk size: 196K
cluster_size: 65536
backing file: /root/test/image/ia32e_rhel7u2_cpu2006.img
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
[root@gr-mrb-64 ~]#