From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNfXv-0007RL-Vd for qemu-devel@nongnu.org; Mon, 28 Jul 2008 23:06:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNfXt-0007Pp-NE for qemu-devel@nongnu.org; Mon, 28 Jul 2008 23:06:43 -0400 Received: from [199.232.76.173] (port=36500 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNfXt-0007Ph-Cb for qemu-devel@nongnu.org; Mon, 28 Jul 2008 23:06:41 -0400 Received: from an-out-0708.google.com ([209.85.132.244]:11492) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNfXs-0007in-Uw for qemu-devel@nongnu.org; Mon, 28 Jul 2008 23:06:41 -0400 Received: by an-out-0708.google.com with SMTP id d18so1752891and.130 for ; Mon, 28 Jul 2008 20:06:40 -0700 (PDT) Message-ID: <488E891E.6000000@codemonkey.ws> Date: Mon, 28 Jul 2008 22:06:06 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow3 - arbitrary metadata References: <56C8EED4-ED25-4F11-B41A-F0937DAE75BF@lvivier.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 Nathaniel McCallum wrote: > On Mon, Jul 28, 2008 at 7:04 PM, Laurent Vivier > wrote: > > > Le 28 juil. 08 à 21:56, Nathaniel McCallum a écrit : > > A project I'm working on requires the ability to store > arbitrary metadata in the VM disk image. Thus, here is a > patch that implements that as qcow3. It basically replaces > the header.backing_store_{offset|size} with > header.metadata_{offset|size}. Metadata is then defined as > NULL-byte separated 'key:value' pairs. The attached qcow3 > then stores the backing file as > 'Backing-File:/home/me/backing_file.img' in the metadata > section. I've included two patches. One is the full patch > against the latest SVN (qcow3.patch). The second patch is > just the diff between qcow2.c and qcow3.c so that you can > easily see the changes. > > I've also wondered if it might be possible to backport these > changes into qcow2 instead of qcow3. However, this would > break older versions of qemu that claim to support qcow2. > > Nathaniel > > > > I think this has already been tried exactly one year ago modifying > snapshot... > > http://www.mail-archive.com/kvm-devel@lists.sourceforge.net/msg05103.html > > but now Fabrice is working on a configuration file, perhaps you > can store your metadata in it. > > > Well, the point is to not have a separate configuration file. > > I've dug up a few more bits of info. First, the offset option will > never work without changing at least qcow2's on disk format. Never is such a strong word. What I was thinking is that you could do the offset thing based on a URI of some sort. For instance: qemu -drive file=offset:foo.img:offset=32,if=ide The syntax of -drive erks me here but you get the gist. Then backing files would work fine. > This is because when you start qemu in snapshot mode, it creates a > new qcow2 image and uses it as the main image. However, the offset > was meant to apply to the underlying image and there is no field in > qcow2 to specify the offset of the backing_file. > > Second, when creating a new qcow2 file, the l1_table_offset is 4096. > There does not appear to be anything stored between the end of the > header and the 4096. So, in theory, you could put anything you want > there. No? There's no guarantee that that space won't be used in future versions of QCOW2 so you can't just cram arbitrary stuff in there. Regards, Anthony Liguori > Nathaniel >