From patchwork Thu Mar 8 22:13:12 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Leonardo E. Reiter" X-Patchwork-Id: 145668 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 7A634B6FC5 for ; Fri, 9 Mar 2012 17:24:42 +1100 (EST) Received: from localhost ([::1]:52673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5sx7-0001Wc-W9 for incoming@patchwork.ozlabs.org; Fri, 09 Mar 2012 01:05:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5laJ-0006nn-Pd for qemu-devel@nongnu.org; Thu, 08 Mar 2012 17:13:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5laH-0003YV-5D for qemu-devel@nongnu.org; Thu, 08 Mar 2012 17:13:19 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:56673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5laG-0003YP-Vq for qemu-devel@nongnu.org; Thu, 08 Mar 2012 17:13:17 -0500 Received: by yenr5 with SMTP id r5so677855yen.4 for ; Thu, 08 Mar 2012 14:13:15 -0800 (PST) Received: by 10.236.200.197 with SMTP id z45mr12611001yhn.99.1331244795807; Thu, 08 Mar 2012 14:13:15 -0800 (PST) Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com [209.85.220.173]) by mx.google.com with ESMTPS id n72sm8211118yhh.21.2012.03.08.14.13.12 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 14:13:15 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so1012302vcb.4 for ; Thu, 08 Mar 2012 14:13:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.138 with SMTP id cu10mr12831240vdb.86.1331244792486; Thu, 08 Mar 2012 14:13:12 -0800 (PST) Received: by 10.220.145.206 with HTTP; Thu, 8 Mar 2012 14:13:12 -0800 (PST) Date: Thu, 8 Mar 2012 16:13:12 -0600 Message-ID: From: "Leonardo E. Reiter" To: QEMU Developers Mailing List X-Gm-Message-State: ALoCoQka+VZFMrTRjo4WQOXyF79TzuzYAxvvcgEh5iH370yvafMsA7+fif8BZPWJ8ih+51KNJsSj X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.173 X-Mailman-Approved-At: Fri, 09 Mar 2012 01:04:39 -0500 Subject: [Qemu-devel] [PATCH 1/5] block: Virtual Bridges VERDE GOW disk image format documentation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org commit 4b7b36f3776247c92615073b6fa0880d0a1ea1fb Author: Leonardo E. Reiter 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 +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. + + 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