Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/10/2010 10:18 AM, Kevin Wolf wrote:
> Am 10.09.2010 17:02, schrieb Anthony Liguori:
>    
>> What makes us future proof is having a good feature support.  qcow2
>> doesn't have this.  We have a good way at making purely informational
>> changes and also making changes that break the format.  Those features
>> are independent so they can be backported in a compatible way too.
>>      
> I might have agreed that it's useful to be able to backport them
> independently if we had had lots of such features added in the past. But
> we haven't.
>    

I think part of why we haven't had them is that the mechanisms aren't 
very flexible.

A good example of where feature support would be very nice is for 
changing the way snapshots metadata is recorded in qcow2.

It would be nice to be able to represent snapshots with a uuid.  If you 
added new metadata that had uuid based snapshots that were hierarchical 
and added a feature bit, it would have some nice properties.

Since most images don't have snapshots, the common case would be a qcow2 
that was fully backwards compatible.  You would also get a graceful 
failure for using a new image with an old QEMU.

You could argue that you can do the same by bumping the version number 
but that really only works when all changes are additive.  If you had 
two features and you only backported one, badness ensues.

On it's own, I don't think feature support is enough to justify a new 
image format.  However, it's a nice thing to have.

Regards,

Anthony Liguori

> The qcow2 mechanism for compatible changes is header extensions (used
> exactly once, for the backing file format) and for incompatible changes
> increasing the version number (never used so far, if you consider qcow1
> and qcow2 completely independent formats, which I think they are).
>
> Kevin
>