qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Fri, 18 Feb 2011 20:11:19 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

Am 18.02.2011 18:43, schrieb Stefan Weil:
> Am 18.02.2011 10:57, schrieb Kevin Wolf:
>> Am 18.02.2011 10:12, schrieb Markus Armbruster:
>>> Kevin Wolf <address@hidden> 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.

I totally agree. qemu-img is known as a Swiss army knife for disk images
and this is definitely a strength.

However, it's not useful just because it supports a high number of
formats, but because these formats are in active use. Most of them are
the native formats of some other software.

I think things look a bit different when we're talking about
qemu-specific formats. qcow1 isn't in use any more because nobody needs
it for compatibility with other software and for use with qemu, there is
qcow2. Still, the qcow1 driver is still around and bitrots.

> 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).

Either I'm misunderstanding what you try to say here, or you
miunderstood what I said. I agree that we don't want to have to do
qemu-img convert (i.e. a full copy) in order to upgrade. This is one of
the reasons why I think we should have a qcow3 which can be upgraded
basically by increasing the version number in the header (look at it as
an incompatible feature flag, if you want) instead of starting something
completely new.

> 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.

> 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!

Basically this is what we did for QED. In hindsight I consider it a
mistake because it set a bad precedence of inventing something new
instead of fixing what's there. I really don't want to convert all my
images each time to take advantage of new qemu version.

Kevin



reply via email to

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