qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Fri, 10 Sep 2010 13:35:05 +0100

On Fri, Sep 10, 2010 at 1:12 PM, Kevin Wolf <address@hidden> wrote:
> Am 10.09.2010 13:43, schrieb Stefan Hajnoczi:
>>>>>> By creating two code paths within qcow2.
>>>>>
>>>>> You're creating two code paths for users.
>>>>
>>>> No, I'm creating a single path: QED.
>>>>
>>>> There are already two code paths: raw and qcow2.  qcow2 has had such a bad
>>>> history that for a lot of users, it's not even a choice.
>>>
>>> qcow2 exists, people use it, and by the time qed is offered on distros (even
>>> more on enterprise distros), there will be a lot more qcow2 images.  Not
>>> everyone runs qemu.git HEAD.
>>>
>>> What will you tell those people?  Upgrade your image?  They may still want
>>> to share it with older installations.  What if they use features not present
>>> in qed?  Bad luck?
>>>
>>> qcow2 is going to live forever no matter what we do.
>>
>> It should be possible to do (live) upgrades for supported images.
>
> 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.

Do you think qcow2 is the right format for the future?  The flagship
disk image format for KVM?

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]