[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] qcow3 - arbitrary metadata
Date: Mon, 28 Jul 2008 15:50:30 -0500
User-agent: Thunderbird (X11/20080501)

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


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]