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.
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"?
Nathaniel