Re: [Qemu-devel] [PATCH] qcow3 - arbitrary metadata

[Anthony Liguori <anthony@codemonkey.ws>]

Nathaniel McCallum wrote:
> On Mon, Jul 28, 2008 at 4:08 PM, Anthony Liguori 
> <anthony@codemonkey.ws <mailto:anthony@codemonkey.ws>> 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
>