Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

[Markus Armbruster]

"Richard W.M. Jones" <address@hidden> writes:

> On Thu, May 24, 2018 at 05:08:17PM +0200, Kevin Wolf wrote:
>> Am 24.05.2018 um 16:56 hat Michael S. Tsirkin geschrieben:
>> > On Thu, May 24, 2018 at 12:32:51PM +0100, Richard W.M. Jones wrote:
>> > > There is however a seed of a good idea in the thread:
>> > > 
>> > > > I don't think QEMU needs to use this information automatically,
>> > > > necessarily.  I think the first step is to simply make QEMU save
>> > > > this information in the disk image, and making qemu-img able to
>> > > > read and write this information.
>> > > 
>> > > It would be nice if qcow2 added arbitrary data sections (which would
>> > > always be ignored by qemu) for storing additional data.  This could be
>> > > used to create a compact qcow2 + metadata format to rival OVA for
>> > > management layers to use, and there are various other uses too.
>> > > 
>> > > Rich.
>> > 
>> > I think this part is pretty uncontroversial.
>> > 
>> > But can we add data without changing the verion?
>> 
>> Yes. Don't worry about where to store it, we'll solve this. Do worry
>> about what to store.
>
> Ideally from my point of view: named blobs.  More formally, any number
> of (key, value) pairs where the key is a simple string, and the value
> is a binary blob.  The binary blobs might really be XML or YAML or an
> icon or whatever, but qemu would not need to look inside them.
>
> We could then attach metadata (in some to-be-decided format) to qcow2
> files and create a compact rival to OVA without needing to encode any
> knowledge of the metadata into qemu at all.
>
> Another use for this is allowing qcow2 files to contain names, titles,
> descriptions, creation date, OS icons, etc. which could be displayed
> in file managers.

Have we just reinvented resource forks?

SCNR ;)