Storing command line options in qcow2 images

Storing command line options in qcow2 images

[Jorge Lucángeli Obes]

Hi Avi, hi all,

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

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.

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.

Cheers,
Jorge

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: 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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Jorge Lucángeli Obes]

On 7/30/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 646 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-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


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

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Storing command line options in qcow2 images

[Andrew Walrond]

Jorge Lucángeli Obes wrote:
> 
> Ideas? Suggestions? I can send the patches for the functionality
> that's implemented right now.
> 

Great idea, and one I would certainly use. I guess then on Windoze I
could associate .qcow2 files with qemu and just double click to run my
VMs? It would be good to get rid of the .bat files and shortcuts I have
to use at the moment to pass args to qemu.

Of course, the ultimate dream would be a single exe file which Windows
users of the VM could just download and run. I guess the only impediment
to this would be the need to distribute the various license files.
Having said that, I wonder if it would be acceptable for them to be
available from a -licenses command line option?

But I'm getting ahead of the game here ;)

Go for it; but as has been said, don't let qemu/kvm diverge...

Andrew Walrond


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Avi Kivity]

Andrew Walrond wrote:
> Jorge Lucángeli Obes wrote:
>   
>> Ideas? Suggestions? I can send the patches for the functionality
>> that's implemented right now.
>>
>>     
>
> Great idea, and one I would certainly use. I guess then on Windoze I
> could associate .qcow2 files with qemu and just double click to run my
> VMs? It would be good to get rid of the .bat files and shortcuts I have
> to use at the moment to pass args to qemu.
>
>   

And on Linux, you can use binfmt-misc (or however it's called), chmod +x 
your .qcow file, and execute it to launch the vm.


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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Anthony Liguori]

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.

Regards,

Anthony Liguori

Jorge Lucángeli Obes wrote:
> Hi Avi, hi all,
>
> 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 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.
>
> 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.
>
> 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.
>
> Cheers,
> Jorge
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Jorge Lucángeli Obes]

On 8/6/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Avi Kivity]

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

Are all the users' images open for breakage too?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Daniel P. Berrange]

On Tue, Aug 07, 2007 at 07:10:17AM +0300, Avi Kivity wrote:
> Anthony Liguori 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.
> >   
> 
> Are all the users' images open for breakage too?

I'd say not. QCow2 has been around for a long time now so breaking compat
with existing images would be a very bad idea. Ideally though some extension
would be both backwards & forwards compatible - eg existing qcow2 impls 
would just ignore any new extension, while new impls would work any image 
with or without extension. If this isn't possible then at least call any
new format qcow3 to make it obvious to users that it is not compatible.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Avi Kivity]

Daniel P. Berrange wrote:
> On Tue, Aug 07, 2007 at 07:10:17AM +0300, Avi Kivity wrote:
>   
>> Anthony Liguori 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.
>>>   
>>>       
>> Are all the users' images open for breakage too?
>>     
>
> I'd say not. QCow2 has been around for a long time now so breaking compat
> with existing images would be a very bad idea. Ideally though some extension
> would be both backwards & forwards compatible - eg existing qcow2 impls 
> would just ignore any new extension, while new impls would work any image 
> with or without extension. If this isn't possible then at least call any
> new format qcow3 to make it obvious to users that it is not compatible.
>   

It was, of course, a rhetorical question.  I initially suggested using a 
special snapshot as a means of preserving compatibility with qcow2, 
which I think is better than introducing yet a new format.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Anthony Liguori]

Avi Kivity wrote:
> Daniel P. Berrange wrote:
>> On Tue, Aug 07, 2007 at 07:10:17AM +0300, Avi Kivity wrote:
>>  
>>> Anthony Liguori 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.
>>>>         
>>> Are all the users' images open for breakage too?
>>>     
>>
>> I'd say not. QCow2 has been around for a long time now so breaking 
>> compat
>> with existing images would be a very bad idea. Ideally though some 
>> extension
>> would be both backwards & forwards compatible - eg existing qcow2 
>> impls would just ignore any new extension, while new impls would work 
>> any image with or without extension. If this isn't possible then at 
>> least call any
>> new format qcow3 to make it obvious to users that it is not compatible.
>>   
>
> It was, of course, a rhetorical question.  I initially suggested using 
> a special snapshot as a means of preserving compatibility with qcow2, 
> which I think is better than introducing yet a new format.

There are still more features I'd like to see added to qcow2 so I'm 
hoping that it's not frozen.  For instance, copy-on-read would be very 
useful.

Regards,

Anthony Liguori

>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Avi Kivity]

Anthony Liguori wrote:
>
> There are still more features I'd like to see added to qcow2 so I'm 
> hoping that it's not frozen.  For instance, copy-on-read would be very 
> useful.
>

qcow2 was released as part of qemu 0.9.0.  People are using it.  How can 
we contemplate non backward compatible changes?



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori 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.
>>   
>>     
>
> Are all the users' images open for breakage too?
>   

FWIW, you can extended the header without causing a breakage.  Just bump 
the version, add the field, and add appropriate code.  Of course, this 
is technically qcow v3 but it's a good opportunity to make things a bit 
sanier such that instead of check version == QCOW_VERSION that version 
 >= QCOW_VERSION.

Regards,

Anthony Liguori

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Jorge Lucángeli Obes]

On 8/8/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:
> Avi Kivity wrote:
> > Anthony Liguori 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.
> >>
> >>
> >
> > Are all the users' images open for breakage too?
> >
>
> FWIW, you can extended the header without causing a breakage.  Just bump
> the version, add the field, and add appropriate code.  Of course, this
> is technically qcow v3 but it's a good opportunity to make things a bit
> sanier such that instead of check version == QCOW_VERSION that version
>  >= QCOW_VERSION.

I think that for now we can try the snapshot-based approach, as it is
the least intrusive one. I wouldn't push for a format change just with
this minor feature. However, I would be glad to convert our code if
the general consensus was that we need a new format.

Patches for our solution follow. They are against:

5b16d32e3785274310e9e1970f4221b4966c5474

Which was userspace a few minutes ago.

Cheers,
Jorge

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: Storing command line options in qcow2 images

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 1604 bytes --]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori 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.
>>>   
>>>     
>> Are all the users' images open for breakage too?
>>   
> 
> FWIW, you can extended the header without causing a breakage.  Just bump 
> the version, add the field, and add appropriate code.  Of course, this 
> is technically qcow v3 but it's a good opportunity to make things a bit 
> sanier such that instead of check version == QCOW_VERSION that version 
>  >= QCOW_VERSION.

It's funny, we had the same kind of discussion about ext3/ext4 some months ago...

The problem with changing qcow version is you prevent people using unmodified
version of qemu to use this disk image.

IMHO, I think the best thing to do is to introduce the command line option in
empty snapshot in current version of qcow2 (so an unmodified version of qemu is
able to use the image, ignoring the command line, and a modified version can use
this new feature). And then, after, thinking about QCOW3 we can define a set of
new functionalities we want to introduce and add "command line in qcow header"
in this set of functionalities.

Regards,
Laurent
-- 
------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


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

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Storing command line options in qcow2 images

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori 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.
>>>       
>>
>> Are all the users' images open for breakage too?
>>   
>
> FWIW, you can extended the header without causing a breakage.  Just 
> bump the version, add the field, and add appropriate code.  Of course, 
> this is technically qcow v3 but it's a good opportunity to make things 
> a bit sanier such that instead of check version == QCOW_VERSION that 
> version >= QCOW_VERSION.
>

This sounds much better.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/