On Mon, Jul 28, 2008 at 4:50 PM, Anthony Liguori
<address@hidden> wrote:
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
I assume this technique is more "mergable"