[Qemu-devel] Re: [kvm-devel] Storing command line options in qcow2 images

[Avi Kivity]

Jorge Lucángeli Obes wrote:
> Hi Avi, hi all,
>
>   

I believe that Laurent (copied) is also interested in this area.

> I've started some (very minor) groundwork for this task. My idea was
> to add an extra "annotation" field in qcow2 snapshots. In this way, a
> snapshot can hold abitrary information; for example, command line
> arguments.
>
> Before going any further, I wanted to validate the general idea with
> the list. 

I've copied qemu-devel as well.  This can benefit qemu as much as kvm 
and I see no reasons that this shouldn't be merged into kvm through qemu 
upstream.  Furthermore, I'd very much hate to see qemu and kvm image 
formats diverge, so I'd like to get the qemu maintainer's approval for 
any format changes or extensions.

> I am planning on using a snapshot with a distinct name to
> store command line options. This approach seems simple yet it is
> powerful enough for what we need to do.
>   

Yes, that seems to be the best idea.  A snapshot name perhaps beginning 
in a '\0' would avoid any ambiguity (much like the separate unix domain 
socket namespace).

> There's a slight overhead as now all qcow2 snapshots have to store a
> extra (probably) empty pointer. An alternative approach would be to
> somehow indicate that some snapshots are "descriptive" snapshots and
> others are "useful" snapshots; however, I felt that this would be more
> complicated.
>   

Will storing an extra pointer break existing qcow2 images?   If so, we'd 
better avoid it.

> I have a working patch to qemu-img that allows storing arbitrary
> annotations into qcow2 images. I developed it as a testing utility.
> Right now annotations are implemented as another string alongside the
> snapshot's 'name' and 'id'. I thought about storing annotations as
> key/value pairs but again, it seemed overkill.
>
> >From here, the plan would be to add a command to qemu-img that allows
> embedding of command line options into qcow2 images. These options
> would be stored in a snapshot with a special name, and qemu would
> check for the presence of this snapshot in order to read command line
> options from the qcow2 image.
>
> Ideas? Suggestions? I can send the patches for the functionality
> that's implemented right now.
>   



--
error compiling committee.c: too many arguments to function