From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FxkXa-00075G-9U for qemu-devel@nongnu.org; Tue, 04 Jul 2006 09:02:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FxkXX-00074V-ED for qemu-devel@nongnu.org; Tue, 04 Jul 2006 09:02:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxkXX-00074S-9D for qemu-devel@nongnu.org; Tue, 04 Jul 2006 09:02:07 -0400 Received: from [32.97.110.154] (helo=e36.co.us.ibm.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FxklD-0003qT-2W for qemu-devel@nongnu.org; Tue, 04 Jul 2006 09:16:15 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k64D25NM011874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Jul 2006 09:02:05 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k64D1PCS045326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Jul 2006 07:01:25 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k64D25Rc024811 for ; Tue, 4 Jul 2006 07:02:05 -0600 Received: from wecm-9-67-93-53.wecm.ibm.com (wecm-9-67-93-53.wecm.ibm.com [9.67.93.53]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k64D24LL024753 for ; Tue, 4 Jul 2006 07:02:04 -0600 Subject: Re: [Qemu-devel] QCow v2 From: Nathaniel McCallum In-Reply-To: <44AA33AD.3030300@bellard.org> References: <1151981142.5476.13.camel@localhost.localdomain> <44AA33AD.3030300@bellard.org> Content-Type: text/plain Date: Tue, 04 Jul 2006 09:01:35 -0400 Message-Id: <1152018095.16023.15.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, 2006-07-04 at 11:23 +0200, Fabrice Bellard wrote: > Hi, > > I am not sure it is interesting to store the configuration of the VM in > the disk image (there can be several disk images for a given VM). > Moreover, extensions to the qcow header must be added at its end. Storing the config in the disk image does not preclude: 1. using multiple disk images with a vm 2. using multiple vm's with a single disk image Nor does it make it more difficult to do any of the above. All it does is make it easier for the use case of one VM with one image, which is the vast majority of VM's out there. In addition, it definitely is interesting to store other random data in the image. Here is a second proposal: We have a key/value section that replaces the backing store section: typedef struct QCowHeader { uint32_t magic; uint32_t version; uint64_t key_val_offset; /* was backing_file_offset */ uint32_t key_val_size; /* was backing_file_size */ uint32_t mtime; uint64_t size; uint8_t cluster_bits; uint8_t l2_bits; uint32_t crypt_method; uint64_t l1_table_offset; } QCowHeader; The above does not change the size of the header. And as such, you can still read the header off the file and determine how to interpret it based on the version number. The key_val section is pairs of null terminated (UTF-8?) strings. The first string in the pair is the key, the second is the value. It could handle the current backing store design like this: "backing_store": "" > Regarding my current plans, the next qcow evolution will be the support > for multiple snapshots. Each snapshot will be tagged by a label. I assume you'll do this with multiple backing stores: "num_backing_stores" : "2" "backing_store_0" : "" "backing_store_0_label": "