Lines Matching refs:of
5 A ``qcow2`` image file is organized in units of constant size, which are called
10 clusters of the same size.
17 The first cluster of a qcow2 image contains the file header::
34 Length of the backing file name in bytes. Must not be
39 Number of bits that are used for addressing an offset
43 Note: QEMU as of today has an implementation limit of 2 MB
53 Note: QEMU has an implementation limit of 32 MB as
60 (56 bits) of populated clusters, and an image may
70 Number of entries in the active L1 table
81 Number of clusters that the refcount table occupies
84 Number of snapshots contained in the image
96 Bitmask of incompatible features. An implementation must
134 Bitmask of compatible features. An implementation can
145 Bitmask of auto-clear features. An implementation may only
168 of only setting the zero flag in the L2 table
178 Describes the width of a reference count block entry (width
185 Length of the header structure in bytes. For version 2
188 of 8.
199 1. If the value of the additional field must not be ignored for correct
200 handling of the file, it will be accompanied by a corresponding incompatible
209 3. An explicit value of 0 will have the same behavior as when the field is not
242 ``header_length`` must be a multiple of 8, which means that if the end of the last
245 the padding, it will be interpreted accordingly to point `[3.] <#ref_rules_3>`_ of the previous
256 0x00000000 - End of the header extension area
265 4 - 7: Length of the header extension data
270 multiple of 8.
276 the remaining space between the end of the header extension area and the end of
279 data of compatible features that it doesn't support. Compatible features that
302 The number of entries in the feature name table is determined by the length of
305 Byte 0: Type of feature (select feature bitmap)
325 The data of the extension should be considered consistent only if the
328 The fields of the bitmaps extension are::
331 The number of bitmaps contained in the image. Must be
340 Size of the bitmap directory in bytes. It is the cumulative
341 size of all (nb_bitmaps) bitmap directory entries.
352 of the ``LUKS`` crypt method. The header extension must be absent for
356 its additional data, as well as the length of such data.
362 Byte 8 - 15: Length of the written encryption header in bytes.
365 to the nearest multiple of the cluster size. Any
371 The first 592 bytes of the header clusters will contain the LUKS
373 The size of the key material data areas is determined by the number of
376 package) for details of the LUKS partition header format.
379 calculated as normal for the LUKS spec. ie the size of the LUKS
381 start of the LUKS header. This offset value is not required to be
383 context of qcow2, since the qcow2 file format itself defines where
388 to the start of the LUKS header clusters in the qcow2 container,
389 not the start of the qcow2 file.
441 to a number of design flaws affecting its security. It is only
442 supported in the command line tools for the sake of back compatibility
456 qcow2 manages the allocation of host clusters by maintaining a reference count
457 for each host cluster. A refcount of 0 means that the cluster is free, 1 means
475 QEMU has an implementation limit of 8 MB as the maximum refcount
476 table size. With a 2 MB cluster size and a default refcount_order of
478 the worst case, with a 512 cluster size and refcount_order of 6, it is
481 Given an offset into the image file, the refcount of its cluster can be
496 9 - 63: Bits 9-63 of the offset into the image file at which the
506 Bit 0 - x: Reference count of the cluster. If refcount_bits implies a
514 Just as for refcounts, qcow2 uses a two-level structure for the mapping of
550 9 - 55: Bits 9-55 of the offset into the image file at which the L2
574 implicit refcount of 1 (because of the fixed host = guest
591 9 - 55: Bits 9-55 of host cluster offset. Must be aligned to a
594 bit 63 set (indicating a host cluster offset of 0) when an
607 x - 61: Number of additional 512-byte sectors used for the
609 in the previous field. Some of these sectors may reside
613 all of the bytes in the final sector; rather, decompression
614 stops when it has produced a cluster of data.
616 Another compressed cluster may map to the tail of the final
628 field of the header.
630 In these images standard data clusters are divided into 32 subclusters of the
631 same size. They are contiguous and start from the beginning of the cluster.
633 indicating the status of each one of them. Compressed data clusters don't have
636 The size of an extended L2 entry is 128 bits so the number of entries per table
644 in the previous section, with the exception of bit 0 of the standard cluster
682 qcow2 supports internal snapshots. Their basic principle of operation is to
683 switch the active L1 table, so that a different set of host clusters are
686 When creating a snapshot, the L1 table should be copied and the refcount of all
690 When loading a snapshot, bit 63 of all entries in the new active L1 table and
694 A directory of all snapshots is stored in the snapshot table, a contiguous area
696 fields snapshots_offset and nb_snapshots. The entries of the snapshot table
697 have variable length, depending on the length of ID, name and extra data.
704 8 - 11: Number of entries in the L1 table of the snapshots
706 12 - 13: Length of the unique ID string describing the snapshot
708 14 - 15: Length of the name of the snapshot
713 20 - 23: Subsecond part of the time at which the snapshot was taken
719 32 - 35: Size of the VM state in bytes. 0 if no VM state is saved.
726 36 - 39: Size of extra data in the table entry (used for future
727 extensions of the format)
733 Byte 40 - 47: Size of the VM state in bytes. 0 if no VM
737 Byte 48 - 55: Virtual disk size of the snapshot in bytes
749 variable: Name of the snapshot (not null terminated)
752 next multiple of 8.
764 Each bit of the bitmap is responsible for strictly defined range of the virtual
771 Granularity is a property of the concrete bitmap, see below.
780 ``bitmap_directory_size``. The entries of the bitmap directory have variable
781 length, depending on the lengths of the bitmap name and extra data.
783 Structure of a bitmap directory entry::
791 Number of entries in the bitmap table of the bitmap.
803 The bitmap must reflect all changes of the virtual
806 type of this bitmap must be 'dirty tracking bitmap'.
820 This field describes the sort of the bitmap.
834 A bitmap's granularity is how many bytes of the image
835 accounts for one bit of the bitmap.
838 Size of the bitmap name. Must be non-zero.
844 Size of type-specific extra data.
856 The name of the bitmap (not null terminated), occupying
861 next multiple of 8. All bytes of the padding must be zero.
868 structures like for refcounts and guest clusters mapping) for the mapping of
875 Structure of a bitmap table entry::
884 9 - 55: Bits 9 - 55 of the host cluster offset. Must be aligned to
903 This offset is not defined if bits 9 - 55 of bitmap table entry are zero (see
907 bit offset into the image file to the corresponding bit of the bitmap can be
914 If the size of the bitmap data is not a multiple of the cluster size then the
915 last cluster of the bitmap data contains some unused tail bits. These bits must
927 corresponding range of the virtual disk (see above) was written to while the