commit 4b7b36f3776247c92615073b6fa0880d0a1ea1fb
Author: Leonardo E. Reiter <[email protected]>
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.
Signed-off-by: Leonardo E. Reiter <[email protected]>
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.
+
+
