* [Qemu-devel] [PATCH v2 1/1] parallels: add format spec
@ 2015-11-23 13:32 Denis V. Lunev
2015-11-26 8:17 ` Stefan Hajnoczi
0 siblings, 1 reply; 3+ messages in thread
From: Denis V. Lunev @ 2015-11-23 13:32 UTC (permalink / raw)
Cc: Vladimir Sementsov-Ogievskiy, qemu-devel, Stefan Hajnoczi,
Denis V. Lunev, John Snow
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
This specifies Parallels image format as implemented in Parallels Cloud
Server 6.10
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: John Snow <jsnow@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
---
v2: add license info
switch to offsets from types in field descriptions
MAINTAINERS | 1 +
docs/specs/parallels.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 228 insertions(+)
create mode 100644 docs/specs/parallels.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 9e1fa72..23441e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1471,6 +1471,7 @@ M: Denis V. Lunev <den@openvz.org>
L: qemu-block@nongnu.org
S: Supported
F: block/parallels.c
+F: docs/specs/parallels.txt
qed
M: Stefan Hajnoczi <stefanha@redhat.com>
diff --git a/docs/specs/parallels.txt b/docs/specs/parallels.txt
new file mode 100644
index 0000000..e58fb7c
--- /dev/null
+++ b/docs/specs/parallels.txt
@@ -0,0 +1,227 @@
+= License =
+
+Copyright (c) 2015 Denis Lunev
+Copyright (c) 2015 Vladimir Sementsov-Ogievskiy
+
+This work is licensed under the terms of the GNU GPL, version 2 or later.
+See the COPYING file in the top-level directory.
+
+= Parallels Expandable Image File Format =
+
+A Parallels expandable image file consists of three consecutive parts:
+ * header
+ * BAT
+ * data area
+
+All numbers in a Parallels expandable image are stored in little-endian byte
+order.
+
+
+== Definitions ==
+
+ Sector A 512-byte data chunk.
+
+ Cluster A data chunk of the size specified in the image header.
+ Currently, the default size is 1MiB (2048 sectors). In previous
+ versions, cluster sizes of 63 sectors, 256 and 252 kilobytes were
+ used.
+
+ BAT Block Allocation Table, an entity that contains information for
+ guest-to-host I/O data address translation.
+
+
+== Header ==
+
+The header is placed at the start of an image and contains the following
+fields:
+
+Bytes:
+ 0 - 15: magic
+ Must contain "WithoutFreeSpace" or "WithouFreSpacExt".
+
+ 16 - 19: version
+ Must be 2.
+
+ 20 - 23: heads
+ Disk geometry parameter for guest.
+
+ 24 - 27: cylinders
+ Disk geometry parameter for guest.
+
+ 28 - 31: tracks
+ Cluster size, in sectors.
+
+ 32 - 35: nb_bat_entries
+ Disk size, in clusters (BAT size).
+
+ 36 - 43: nb_sectors
+ Disk size, in sectors.
+
+ For "WithoutFreeSpace" images:
+ Only the lowest 4 bytes are used. The highest 4 bytes must be
+ cleared in this case.
+
+ For "WithouFreSpacExt" images, there are no such
+ restrictions.
+
+ 44 - 47: in_use
+ Set to 0x746F6E59 when the image is opened by software in R/W
+ mode; set to 0x312e3276 when the image is closed.
+
+ A zero in this field means that the image was opened by an old
+ version of the software that doesn't support Format Extension
+ (see below).
+
+ Other values are not allowed.
+
+ 48 - 51: data_off
+ An offset, in sectors, from the start of the file to the start of
+ the data area.
+
+ For "WithoutFreeSpace" images:
+ - If data_off is zero, the offset is calculated as the end of BAT
+ table plus some padding to ensure sector size alignment.
+ - If data_off is non-zero, the offset should be aligned to sector
+ size. However it is recommended to align it to cluster size for
+ newly created images.
+
+ For "WithouFreSpacExt" images:
+ data_off must be non-zero and aligned to cluster size.
+
+ 52 - 55: flags
+ Miscellaneous flags.
+
+ Bit 0: Empty Image bit. If set, the image should be
+ considered clear.
+
+ Bits 2-31: Unused.
+
+ 56 - 63: ext_off
+ Format Extension offset, an offset, in sectors, from the start of
+ the file to the start of the Format Extension Cluster.
+
+ ext_off must meet the same requirements as cluster offsets
+ defined by BAT entries (see below).
+
+
+== BAT ==
+
+BAT is placed immediately after the image header. In the file, BAT is a
+contiguous array of 32-bit unsigned little-endian integers with
+(bat_entries * 4) bytes size.
+
+Each BAT entry contains an offset from the start of the file to the
+corresponding cluster. The offset set in clusters for "WithouFreSpacExt" images
+and in sectors for "WithoutFreeSpace" images.
+
+If a BAT entry is zero, the corresponding cluster is not allocated and should
+be considered as filled with zeroes.
+
+Cluster offsets specified by BAT entries must meet the following requirements:
+ - the value must not be lower than data offset (provided by header.data_off
+ or calculated as specified above),
+ - the value must be lower than the desired file size,
+ - the value must be unique among all BAT entries,
+ - the result of (cluster offset - data offset) must be aligned to cluster
+ size.
+
+
+== Data Area ==
+
+The data area is an area from the data offset (provided by header.data_off or
+calculated as specified above) to the end of the file. It represents a
+contiguous array of clusters. Most of them are allocated by the BAT, some may
+be allocated by the ext_off field in the header while other may be allocated by
+extensions. All clusters allocated by ext_off and extensions should meet the
+same requirements as clusters specified by BAT entries.
+
+
+== Format Extension ==
+
+The Format Extension is an area 1 cluster in size that provides additional
+format features. This cluster is addressed by the ext_off field in the header.
+The format of the Format Extension area is the following:
+
+ 0 - 7: magic
+ Must be 0xAB234CEF23DCEA87
+
+ 8 - 23: m_CheckSum
+ The MD5 checksum of the entire Header Extension cluster except
+ the first 24 bytes.
+
+ The above are followed by feature sections or "extensions". The last
+ extension must be "End of features" (see below).
+
+Each feature section has the following format:
+
+ 0 - 7: magic
+ The identifier of the feature:
+ 0x0000000000000000 - End of features
+ 0x20385FAE252CB34A - Dirty bitmap
+
+ 8 - 15: flags
+ External flags for extension:
+
+ Bit 0: NECESSARY
+ If the software cannot load the extension (due to an
+ unknown magic number or error), the file should not be
+ changed. If this flag is unset and there is an error on
+ loading the extension, said extension should be dropped.
+
+ Bit 1: TRANSIT
+ If there is an unknown extension with this flag set,
+ said extension should be left as is.
+
+ If neither NECESSARY nor TRANSIT are set, the extension should be
+ dropped.
+
+ 16 - 19: data_size
+ The size of the following feature data, in bytes.
+
+ 20 - 23: unused32
+ Align header to 8 bytes boundary.
+
+ variable: data (data_size bytes)
+
+ The above is followed by padding to the next 8 bytes boundary, then the
+ next extension starts.
+
+ The last extension must be "End of features" with all the fields set to 0.
+
+
+=== Dirty bitmaps feature ===
+
+This feature provides a way of storing dirty bitmaps in the image. The fields
+of its data area are:
+
+ 0 - 7: size
+ The bitmap size, should be equal to disk size in sectors.
+
+ 8 - 23: id
+ An identifier for backup consistency checking.
+
+ 24 - 27: granularity
+ Bitmap granularity, in sectors. I.e., the number of sectors
+ corresponding to one bit of the bitmap.
+
+ 28 - 31: l1_size
+ The number of entries in the L1 table of the bitmap.
+
+ variable: l1 (64 * l1_size bytes)
+ L1 offset table (in bytes)
+
+A dirty bitmap is stored using a one-level structure for the mapping to host
+clusters - an L1 table.
+
+Given an offset into the bitmap, the offset in bytes into the image file can be
+obtained as follows:
+
+ offset = l1_table[offset / cluster_size] + (offset % cluster_size)
+
+If an L1 table entry is 0, the corresponding cluster of the bitmap is assumed
+to be zero.
+
+If an L1 table entry is 1, the corresponding cluster of the bitmap is assumed
+to have all bits set.
+
+If an L1 table entry is not 0 or 1, it allocates a cluster from the data area.
--
2.1.4
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [Qemu-devel] [PATCH v2 1/1] parallels: add format spec
2015-11-23 13:32 [Qemu-devel] [PATCH v2 1/1] parallels: add format spec Denis V. Lunev
@ 2015-11-26 8:17 ` Stefan Hajnoczi
2015-11-26 10:13 ` Vladimir Sementsov-Ogievskiy
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Hajnoczi @ 2015-11-26 8:17 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: John Snow, Vladimir Sementsov-Ogievskiy, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
On Mon, Nov 23, 2015 at 04:32:37PM +0300, Denis V. Lunev wrote:
> From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>
> This specifies Parallels image format as implemented in Parallels Cloud
> Server 6.10
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Eric Blake <eblake@redhat.com>
> CC: John Snow <jsnow@redhat.com>
> CC: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> v2: add license info
> switch to offsets from types in field descriptions
Cool! Thanks for publishing a specification. This will help everyone
understand the code.
> +=== Dirty bitmaps feature ===
> +
> +This feature provides a way of storing dirty bitmaps in the image. The fields
> +of its data area are:
> +
> + 0 - 7: size
> + The bitmap size, should be equal to disk size in sectors.
> +
> + 8 - 23: id
> + An identifier for backup consistency checking.
> +
> + 24 - 27: granularity
> + Bitmap granularity, in sectors. I.e., the number of sectors
> + corresponding to one bit of the bitmap.
Does this need to be a power of 2?
> + 28 - 31: l1_size
> + The number of entries in the L1 table of the bitmap.
> +
> + variable: l1 (64 * l1_size bytes)
> + L1 offset table (in bytes)
> +
> +A dirty bitmap is stored using a one-level structure for the mapping to host
> +clusters - an L1 table.
> +
> +Given an offset into the bitmap, the offset in bytes into the image file can be
What are the units of the offset into the bitmap? Is it a bit number
(i.e. sector number / granularity)?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH v2 1/1] parallels: add format spec
2015-11-26 8:17 ` Stefan Hajnoczi
@ 2015-11-26 10:13 ` Vladimir Sementsov-Ogievskiy
0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2015-11-26 10:13 UTC (permalink / raw)
To: Stefan Hajnoczi, Denis V. Lunev; +Cc: John Snow, qemu-devel
On 26.11.2015 11:17, Stefan Hajnoczi wrote:
> On Mon, Nov 23, 2015 at 04:32:37PM +0300, Denis V. Lunev wrote:
>> From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>
>> This specifies Parallels image format as implemented in Parallels Cloud
>> Server 6.10
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> CC: Eric Blake <eblake@redhat.com>
>> CC: John Snow <jsnow@redhat.com>
>> CC: Stefan Hajnoczi <stefanha@redhat.com>
>> ---
>> v2: add license info
>> switch to offsets from types in field descriptions
> Cool! Thanks for publishing a specification. This will help everyone
> understand the code.
>
>> +=== Dirty bitmaps feature ===
>> +
>> +This feature provides a way of storing dirty bitmaps in the image. The fields
>> +of its data area are:
>> +
>> + 0 - 7: size
>> + The bitmap size, should be equal to disk size in sectors.
>> +
>> + 8 - 23: id
>> + An identifier for backup consistency checking.
>> +
>> + 24 - 27: granularity
>> + Bitmap granularity, in sectors. I.e., the number of sectors
>> + corresponding to one bit of the bitmap.
> Does this need to be a power of 2?
Good point
>
>> + 28 - 31: l1_size
>> + The number of entries in the L1 table of the bitmap.
>> +
>> + variable: l1 (64 * l1_size bytes)
>> + L1 offset table (in bytes)
>> +
>> +A dirty bitmap is stored using a one-level structure for the mapping to host
>> +clusters - an L1 table.
>> +
>> +Given an offset into the bitmap, the offset in bytes into the image file can be
> What are the units of the offset into the bitmap? Is it a bit number
> (i.e. sector number / granularity)?
No, here bitmap is considered as raw data, stored using L1, so offset is
in bytes. Bytes of the bitmap itself, as raw binary data.
--
Best regards,
Vladimir
* now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-26 10:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-23 13:32 [Qemu-devel] [PATCH v2 1/1] parallels: add format spec Denis V. Lunev
2015-11-26 8:17 ` Stefan Hajnoczi
2015-11-26 10:13 ` Vladimir Sementsov-Ogievskiy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).