Re: [Qemu-devel] Re: Strategic decision: COW format

[Stefan Hajnoczi]

On Fri, Feb 18, 2011 at 7:11 PM, Kevin Wolf <address@hidden> wrote:
> Am 18.02.2011 18:43, schrieb Stefan Weil:
>> Is maintaining an additional file format really so much work?
>> I have only some personal experience with vdi.c, and there maintainance
>> was largely caused by interface changes and done by Kevin.
>> Hopefully interfaces will stabilize, so changes will become less frequent.
>
> Well, there are different types of "maintenance".
>
> It's not much work to just drop the code into qemu and let it bitrot.
> This is what happens to the funky formats like bochs or dmg. They are
> usually patches enough so that they still build, but nobody tries if
> they actually work.
>
> Then there are formats in which there is at least some interest, like
> vmdk or vdi. Occasionally they get some fixes, they are probably fine
> for image conversion, but I wouldn't really trust them for production use.
>
> And then there's raw and qcow2, which are used by a lot of people for
> running VMs, that are actively maintained, get a decent level of review
> and fixes etc. Getting a format into this group really takes a lot of
> work. Taking something like FVD would only make sense if we are willing
> to do that work - I mean, really nobody wants to convert from/to a file
> format that isn't implemented anywhere else.

This is a good thing to agree on so I want to reiterate:

There are two types of image formats in QEMU today.

1. Native formats that are maintained and suitable for running VMs.
This includes raw, qcow2, and qed.

2. Convert-only formats that may not be maintained and are not
suitable for running VMs.  All other formats in qemu.git.

The convert-only formats have synchronous implementations which makes
it a bad idea to run VMs with them.  They don't fit into QEMU's
event-driven architecture and will cause poor performance and possible
hangs.

I hope folks agree on this.

The next step is to consider that native support requires at least an
order of magnitude more work and code.  It would be wise to focus on a
flagship format in order to share that effort.  So I think this thread
is a useful discussion to have even if no one can be forced to
collaborate on just one format.

Kevin's position seems to be that an evolution of qcow2 is best for
code maintenance and reuse.

The position that QED and FVD have taken is to start from a clean
slate in order to make incompatible changes and leave out problematic
features.

I think we can get there eventually with either approach but we'll be
introducing incompatible changes either way.  In terms of code reuse,
it's initially nice to share code with qcow2 but in the long run the
two formats might diverge far enough that it becomes a liability due
to extra complexity.

For reference, here is the QCOW3 roadmap wiki page:
http://wiki.qemu.org/Qcow3_Roadmap
Here is the QED outstanding work page:
http://wiki.qemu.org/Features/QED/OutstandingWork

Does FVD have a roadmap or future features?

Stefan