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

[Aurelien Jarno]

On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote:
> Am 18.02.2011 10:12, schrieb Markus Armbruster:
> > Kevin Wolf <address@hidden> writes:
> > 
> >> Am 15.02.2011 20:45, schrieb Chunqiang Tang:
> >>>> Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
> >>>> As you requested, I set up a wiki page for FVD at 
> >>> http://wiki.qemu.org/Features/FVD
> >>>> . It includes a summary of FVD, a detailed specification of FVD, and a 
> >>>> comparison of the design and performance of FVD and QED. 
> >>>
> >>>> See the figure at http://wiki.qemu.org/Features/FVD/Compare . This 
> >>> figure 
> >>>> shows that the file creation throughput of NetApp's PostMark benchmark 
> >>> under 
> >>>> FVD is 74.9% to 215% higher than that under QED.
> >>>
> >>> Hi Anthony,
> >>>
> >>> Please let me know if more information is needed. I would appreciate your 
> >>> feedback and advice on the best way to proceed with FVD. 
> >>
> >> 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.
> 

I agree that the best would be to have a single format, and it's
probably a goal to have. That said, what is most important to my view is
having one or two formats which together have _all_ the features (and 
here I consider speed as a feature) of the existing qcow2 format. QED or
FVD have been designed with the "virtualization in a datacenter" in mind,
and are very good for this use. OTOH they don't support compression or 
snapshotting, that are quite useful for demo, debugging, testing, or
even for occasionally running a Windows VM, in other words in situations
where the speed is not the priority.

If we can't find a tradeoff for that, we should go for two instead of 
one image format.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net