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

[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

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

[Jorge Lucángeli Obes]

On 7/30/07, Avi Kivity <avi@qumranet.com> wrote:
> Jorge Lucángeli Obes wrote:
> > Hi Avi, hi all,
>
> I believe that Laurent (copied) is also interested in this area.

Copied him.

> > 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.

Agreed.

> > 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.

It could be a problem, I agree. Maybe it's a better idea not to touch
the on-disk format. That would mean leaving 'struct
QCowSnapshotHeader' intact, and using existing fields to store our
information. The header includes an "extra_data_size" field that can
do the trick. This would of course need approval from qemu developers.

Laurent, do you want the patches for the functionality that's working
right now? We can divide the (not very big amount of) work that's
left. It consists basically on teaching qemu how to look for command
line options, if none are present on the current invocation. I don't
mind doing it by myself if you want to keep working on the other stuff
you've been posting patches about.

Just to be clear, the actual "embedding" of command line options into
the image would be done with qemu-img. It would be qemu's job to
validate this when the image is loaded.

Another way to do this could be to add an option to qemu that does the
embedding. This would have the benefit of free option validation, but
I felt that image-related operations should be used from qemu-img.

Cheers,
Jorge

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

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Jorge Lucángeli Obes wrote:
[...]
> Laurent, do you want the patches for the functionality that's working
> right now? We can divide the (not very big amount of) work that's
> left. It consists basically on teaching qemu how to look for command
> line options, if none are present on the current invocation. I don't
> mind doing it by myself if you want to keep working on the other stuff
> you've been posting patches about.

Yes, send me your patches and tell me what I can do for you.

Regards,
Laurent
-- 
------------- Laurent.Vivier@bull.net  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jorge Lucángeli Obes]

On 8/6/07, Anthony Liguori <anthony@codemonkey.ws> wrote:
> I don't think adding annotations as snapshots is the right approach.  I
> think proper support should be added in the header.  I wouldn't be too
> concerned with breaking compatibility in qcow2.  That's why it's qcow2
> and not just an updated version of qcow, qcow2 is still, AFAIK, open for
> breakage.

I think I'm fine either way. Avi suggested the snapshot-based
implementation so Laurent and I started working in that direction. We
are now close to finishing the basic functionality. That's not to say
that our solution should be accepted because it's almost ready. I
would like to reach consensus for the way in which all this should be
implemented.

The advantage of the snapshot-based approach is, as it has already
been discussed, its backwards-compatibility. I also think that it
requires less changes to the source code. I am not very familiar with
QEMU development so I'm not able to tell whether or not qcow2 is open
for breakage. I guess we decided to play it safe.

The header-based implementation would be conceptually easier of
course. It would have the added benefit of not having to deal with the
possible use of an empty snapshot (i.e., one with command line
options) in loadvm. That's the only thing left to fix in our current
implementation.

As I said, I'm fine either way. I have a final tomorrow, but after
that I will post our patches for review.

Cheers,
Jorge