From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fxhte-0006t3-K2 for qemu-devel@nongnu.org; Tue, 04 Jul 2006 06:12:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fxhtd-0006sV-Na for qemu-devel@nongnu.org; Tue, 04 Jul 2006 06:12:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fxhtd-0006sP-H4 for qemu-devel@nongnu.org; Tue, 04 Jul 2006 06:12:45 -0400 Received: from [84.96.92.61] (helo=sMtp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fxi7H-0005Uw-Ji for qemu-devel@nongnu.org; Tue, 04 Jul 2006 06:26:51 -0400 Received: from [84.102.211.189] by sp604002mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0J1V00C8WGS3PAQ0@sp604002mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Tue, 04 Jul 2006 11:24:03 +0200 (CEST) Date: Tue, 04 Jul 2006 11:23:57 +0200 From: Fabrice Bellard Subject: Re: [Qemu-devel] QCow v2 In-reply-to: <1151981142.5476.13.camel@localhost.localdomain> Message-id: <44AA33AD.3030300@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <1151981142.5476.13.camel@localhost.localdomain> 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 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. Regarding my current plans, the next qcow evolution will be the support for multiple snapshots. Each snapshot will be tagged by a label. Fabrice. Nathaniel McCallum wrote: > Mark's notes on the qcow format got me to thinking how useful it would > be to be able to store other information in the qcow image itself. For > instance you could store the configuration for the virtual machine in > the image which could be extracted and then start the virtual machine. > > So... I'm proposing that the qcow image be extended to support this > scenario. Something as simple as: > > typedef struct QCowHeader { > uint32_t magic; > uint32_t version; > > uint8_t embedded_data_type; > uint64_t embedded_data_offset; > uint32_t embedded_data_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; > > Thus, embedded_data_type is a constant signifying the type of the data. > embedded_data_type could be a string, etc. Of course, there are a million > other ways this could be implemented. The idea being that we could store > more than just backing store. > > One possible application could be that you could store config info in > the image and have a qemu-loader app that extracts the info and starts > the virtual machine. Another application could be just misc. metadata: > copyright, contact info, VM version, etc... > > I can provide a patch to block-qcow.c if there is interest. > > Nathaniel > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > >