On Fri, Sep 10, 2010 at 1:47 PM, Avi Kivity <a...@redhat.com> wrote:
> On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote:
>>
>>> That still leaves those qcow2 images that use features not supported by
>>> qed. Just a few features missing in qed are internal snapshots, qcow2 on
>>> block devices, compression, encryption. So qed can't be a complete
>>> replacement for qcow2 (and that was the whole point of doing qed). If
>>> anything, it can exist besides qcow2.
>>
>> qcow2 is a feature-driven format. It sacrifices some of the core
>> qualities of an image format in exchange for advanced features. I
>> like to use qcow2 myself for desktop virtualization.
>>
>> qed applies the 80/20 rule to disk image formats. Let's perfect the
>> basics for most users at a fraction of the {development,performance}
>> cost.
>>
>> Then, with a clean base that takes on board the lessons of existing
>> formats it is much easier to innovate. Look at the image streaming,
>> defragmentation, and trim ideas that are playing out right now. I
>> think the reason we haven't seen them before is because the effort and
>> the baggage of doing them is too great. Sure, we maintain existing
>> formats but I don't see active development pushing virtualized storage
>> happening.
>
> The same could be said about much of qemu. It is an old code base that
> wasn't designed for virtualization. Yet we maintain it and develop it
> because compatibility is king.
For compatibility? I figured the amount of effort to implement all
the device emulation and BIOS was not deemed worth starting from
scratch.
Stefan
