Re: Storing command line options in qcow2 images

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

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/