"Richard W.M. Jones" <rjo...@redhat.com> 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 ;)