From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNZgT-0003AZ-Eg for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:51:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNZgQ-0003AN-UW for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:51:08 -0400 Received: from [199.232.76.173] (port=51973 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNZgQ-0003AK-Pr for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:51:06 -0400 Received: from py-out-1112.google.com ([64.233.166.183]:7136) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNZgQ-0001kL-IP for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:51:06 -0400 Received: by py-out-1112.google.com with SMTP id p76so3474977pyb.10 for ; Mon, 28 Jul 2008 13:51:05 -0700 (PDT) Message-ID: <488E3116.9030809@codemonkey.ws> Date: Mon, 28 Jul 2008 15:50:30 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow3 - arbitrary metadata References: <488E2752.7030008@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 Nathaniel McCallum wrote: > On Mon, Jul 28, 2008 at 4:08 PM, Anthony Liguori > > wrote: > > Nathaniel McCallum wrote: > > 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. > > > Can you provide more information about what the metadata is used > for and why it's so important for the metadata to be in the image > verses in a separate file? > > > Ease of use primarily. Take the case of a VM appliance. I would > build a VM appliance and in the metadata I would put: > 1. My company's logo (which would show up as the icon on the file in > any file browser) > 2. All the correct config for how to make the VM implementation start > this image > 3. A first-run startup message with instructions > 4. A click-through license agreement > > The user would download and double-click a single file and the VM > would start up, ask me to agree to a license, provide me the > instructions on how to begin and just start running. > > I could put all this in a separate file, but then the user would have > to unzip it and how does the emulation platform know what to do, etc... > > > > There are other possible ways of doing this that are less > invasive. For instance, you could have a fake snapshot in the > image that just contained your key values pairs. > > Introducing a whole new format is a pretty big change especially > since you're duplicating a ton of code. > > > I agree, a less invasive way would be preferred. However, how would > you create a hidden snapshot (so that qemu doesn't try to load it)? > Perhaps modify qemu to ignore snapshots named ".hidden"? Something that would be pretty interesting, but also terribly hacky, would be to have an option that would allow one to use a disk with an offset. For instance: qemu-system-x86_64 -drive file=foo.img,offset=4096,if=ide Then you could have whatever stuff you wanted in the first 4096 of the disk image. Regards, Anthony Liguori > Nathaniel >