On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote: > Am 18.02.2011 10:12, schrieb Markus Armbruster: > > Kevin Wolf <kw...@redhat.com> 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 aurel...@aurel32.net http://www.aurel32.net
