Re: Storing command line options in qcow2 images

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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/