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

[Stefan Weil <weil@mail.berlios.de>]

Am 18.02.2011 10:57, schrieb Kevin Wolf:
> Am 18.02.2011 10:12, schrieb Markus Armbruster:
>> Kevin Wolf <kwolf@redhat.com> writes:
>>
>>> Yet another file format with yet another implementation is definitely
>>> not what we need. We should probably take some of the ideas in FVD and
>>> consider them for qcow3.
>>
>> Got an assumption there: that the one COW format we need must be qcow3,
>> i.e. an evolution of qcow2. Needs to be justified. If that discussion
>> has happened on the list already, I missed it. If not, it's overdue,
>> and then we better start it right away.
>
> Right. I probably wasn't very clear about what I mean with qcow3 either,
> so let me try to summarize my reasoning.
>
>
> The first point is an assumption that you made, too: That we want to
> have only one format. I hope it's easy to agree on this, duplication is
> bad and every additional format creates new maintenance burden,
> especially if we're taking it serious. Until now, there were exactly two
> formats for which we managed to do this, raw and qcow2. raw is more or
> less for free, so with the introduction of another format, we basically
> double the supported block driver code overnight (while not doubling the
> number of developers).
>
> The consequence of having only one file format is that it must be able
> to obsolete the existing ones, most notably qcow2. We can only neglect
> qcow1 today because we can tell users to use qcow2. It supports
> everything that qcow1 supports and more. We couldn't have done this if
> qcow2 lacked features compared to qcow1.
>
> So the one really essential requirement that I see is that we provide a
> way forward for _all_ users by maintaining all of qcow2's features. This
> is the only way of getting people to not stay with qcow2.


The support of several different file formats is one of the
strong points of QEMU, at least in my opinion.

Reducing this to offline conversion would be a bad idea because it costs
too much time and disk space for quick tests (for production environments,
this might be totally different).

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.

A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!

Maybe adding a staging tree (like for the linux kernel) for experimental
drivers, devices, file formats, tcg targets and so on would make it easier
to add new code and reduce the need for QEMU forks. I'd appreciate such
or any other solution which allows this very much!

Regards,
Stefan