[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH 1/5] block: Virtual Bridges VERDE GOW disk image for
|
From: |
Leonardo E. Reiter |
|
Subject: |
[Qemu-devel] [PATCH 1/5] block: Virtual Bridges VERDE GOW disk image format documentation |
|
Date: |
Thu, 8 Mar 2012 16:13:12 -0600 |
commit 4b7b36f3776247c92615073b6fa0880d0a1ea1fb
Date: Thu Mar 8 15:50:55 2012 -0600
Documentation for Virtual Bridges GOW version 1, 2, and 3 disk image formats. Includes products consuming these disk image formats, basic overview of how they work, and example use case for remote disk image synchronization.
diff --git a/docs/vb-gow.txt b/docs/vb-gow.txt
new file mode 100644
index 0000000..e2ba64b
--- /dev/null
+++ b/docs/vb-gow.txt
@@ -0,0 +1,71 @@
+Virtual Bridges GOW Disk Image formats
+======================================
+GOW has 3 versions that covers the following products:
+ v1: (circa 2006) Win4Lin Pro, Win4BSD, Win4Solaris
+ v2: (circa 2008) Virtual Bridges VERDE,
+ IBM Virtual Desktop for Smart Business
+ v3: (circa 2009) Virtual Bridges VERDE,
+ IBM Virtual Desktop for Smart Business
+
+Current versions of VERDE and IBM Virtual Desktop for Smart Business use both
+versions 2 and 3 in virtual machines to store user images and gold images,
+respectively. Older versions of VERDE (prior to 2009) used only version 2.
+
+What is GOW?
+============
+GOW stands for "Grow on Write", which is a very simple disk image format that
+grows by 64KB blocks when data is added to disk images. Data added to existing
+allocated areas do not result in growth of course. There is no compression
+other than that explicitly available by not having to allocate unused blocks
+in order to handle data beyond them. A simple header at the beginning of the
+image file maps logical blocks (from the guest's perspective) to file offsets
+(from the host's perspective).
+This image format is optimized for product virtual desktop use cases only, and
+has been in mainstream use since 2006. Both Virtual Bridges and IBM sell
+new versions of this technology worldwide at the time of this writing.
+GOW implementation memory maps the allocation map in order to reduce additional
+file-level system calls during normal operation. It supports both read-only
+and read-write images.
+
+Differences Between Versions
+============================
+Version 1 supports disk images of up to 64GB logical size, with an approximate
+4MB header overhead.
+Version 2 supports disk images of up to 256GB logical size, with an approximate
+16MB header overhead. It also aligned file offsets of logical sectors to 512-
+byte boundaries (starting at the first such boundary following the header).
+Version 3 supports disk images of up to 256GB logical size, with an approximate
+32MB header overhead. It is identical to GOW2 except that it also tracks
+block-level version numbers, incrementing (once-per-session) them on changes
+or new allocation. This allows for very easy delta size calculations when
+synchronizing images with external tools (see below).
+File offsets in headers are expressed in 64KB blocks. Block 0 starts
+immediately after the header for each version. In GOW2 and GOW3, block 0
+is actually aligned to a 512 byte boundary beyond the header. Using 64KB
+blocks allows the use of 32-bit unsigned integers in the header itself, rather
+than 64-bit integers, to store offsets even for large files. This cuts the
+header size requirement in half while adding only a minimal shift overhead to
+offset calculations.
+
+Advanced Use Case: Synchronizing Remote Images from Master
+==========================================================
+One of the technologies VERDE provides is "decentralized" virtual desktops.
+This means a gold master image living in the data center can be cached on
+either local desktop(s) or local server(s) to use offline or in a decentralized
+way. This assumes that the consumer is using the virtual desktop image in COW
+mode, with no changes to the image file committed back to it.
+In this scenario, it is easy to do block-level delta downloads from the master
+image that can even be interrupted and resumed from partial downloads.
+The consumer need only to copy blocks from the master image file that have
+a newer version number in the image's header than the local block.
+
+License
+=======
+Virtual Bridges GOW functionality is licensed under BSD-style terms that
+are identical to how most QEMU source files are licensed, including vl.c.
+Please check the respective source files for the comment header with this
+license stated explicitly.
+
+Copyright (C) 1984-2012 Virtual Bridges, Inc. All Rights Reserved.
+
+
- [Qemu-devel] [PATCH 1/5] block: Virtual Bridges VERDE GOW disk image format documentation,
Leonardo E. Reiter <=