Le 28 juil. 08 à 21:56, Nathaniel McCallum a écrit :
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.
I've also wondered if it might be possible to backport these changes into qcow2 instead of qcow3. However, this would break older versions of qemu that claim to support qcow2.
Nathaniel
<qcow3.patch><qcow2-qcow3.patch>
I think this has already been tried exactly one year ago modifying snapshot...
http://www.mail-archive.com/address@hidden/msg05103.html
but now Fabrice is working on a configuration file, perhaps you can store your metadata in it.
Well, the point is to not have a separate configuration file.
I've dug up a few more bits of info. First, the offset option will never work without changing at least qcow2's on disk format. This is because when you start qemu in snapshot mode, it creates a new qcow2 image and uses it as the main image. However, the offset was meant to apply to the underlying image and there is no field in qcow2 to specify the offset of the backing_file.
Second, when creating a new qcow2 file, the l1_table_offset is 4096. There does not appear to be anything stored between the end of the header and the 4096. So, in theory, you could put anything you want there. No?
Nathaniel