From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49046 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3NY-0004MR-BV for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:10:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou3NW-0000zz-Hg for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:10:56 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:39707) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou3NW-0000zt-Dk for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:10:54 -0400 Received: by vws19 with SMTP id 19so2611136vws.4 for ; Fri, 10 Sep 2010 06:10:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C8A28C5.9010704@redhat.com> References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84E738.3020802@codemonkey.ws> <4C865187.6090508@redhat.com> <4C865CFE.7010508@codemonkey.ws> <4C8663C4.1090508@redhat.com> <4C866773.2030103@codemonkey.ws> <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com> <4C88D7CC.5000806@codemonkey.ws> <4C8A1311.8070903@redhat.com> <4C8A20B8.1040800@redhat.com> <4C8A28C5.9010704@redhat.com> Date: Fri, 10 Sep 2010 14:10:53 +0100 Message-ID: Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On Fri, Sep 10, 2010 at 1:47 PM, Avi Kivity wrote: > =A0On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote: >> >>> That still leaves those qcow2 images that use features not supported by >>> qed. Just a few features missing in qed are internal snapshots, qcow2 o= n >>> block devices, compression, encryption. So qed can't be a complete >>> replacement for qcow2 (and that was the whole point of doing qed). If >>> anything, it can exist besides qcow2. >> >> qcow2 is a feature-driven format. =A0It sacrifices some of the core >> qualities of an image format in exchange for advanced features. =A0I >> like to use qcow2 myself for desktop virtualization. >> >> qed applies the 80/20 rule to disk image formats. =A0Let's perfect the >> basics for most users at a fraction of the {development,performance} >> cost. >> >> Then, with a clean base that takes on board the lessons of existing >> formats it is much easier to innovate. =A0Look at the image streaming, >> defragmentation, and trim ideas that are playing out right now. =A0I >> think the reason we haven't seen them before is because the effort and >> the baggage of doing them is too great. =A0Sure, we maintain existing >> formats but I don't see active development pushing virtualized storage >> happening. > > The same could be said about much of qemu. =A0It is an old code base that > wasn't designed for virtualization. =A0Yet we maintain it and develop it > because compatibility is king. For compatibility? I figured the amount of effort to implement all the device emulation and BIOS was not deemed worth starting from scratch. Stefan