From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39563 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou2T5-0006c7-8G for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:12:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou2Sy-0000jC-MS for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:12:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53220) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou2Sy-0000im-GD for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:12:28 -0400 Message-ID: <4C8A20B8.1040800@redhat.com> Date: Fri, 10 Sep 2010 14:12:40 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi Am 10.09.2010 13:43, schrieb Stefan Hajnoczi: >>>>> By creating two code paths within qcow2. >>>> >>>> You're creating two code paths for users. >>> >>> No, I'm creating a single path: QED. >>> >>> There are already two code paths: raw and qcow2. qcow2 has had such a bad >>> history that for a lot of users, it's not even a choice. >> >> qcow2 exists, people use it, and by the time qed is offered on distros (even >> more on enterprise distros), there will be a lot more qcow2 images. Not >> everyone runs qemu.git HEAD. >> >> What will you tell those people? Upgrade your image? They may still want >> to share it with older installations. What if they use features not present >> in qed? Bad luck? >> >> qcow2 is going to live forever no matter what we do. > > It should be possible to do (live) upgrades for supported images. That still leaves those qcow2 images that use features not supported by qed. Just a few features missing in qed are internal snapshots, qcow2 on 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. Kevin