From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54077 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsGpV-0001Tq-9O for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:40:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsGpP-0002kL-PP for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:40:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsGpP-0002k8-6R for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:40:35 -0500 Message-ID: <4D6529DA.1080701@redhat.com> Date: Wed, 23 Feb 2011 17:38:02 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <4D5E8031.5020402@codemonkey.ws> <4D637A20.9020307@redhat.com> <4D650F10.3060900@redhat.com> <4D651858.9040106@codemonkey.ws> <4D652675.1070908@redhat.com> <20110223153304.GI26589@redhat.com> In-Reply-To: <20110223153304.GI26589@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , Chunqiang Tang On 02/23/2011 05:33 PM, Daniel P. Berrange wrote: > On Wed, Feb 23, 2011 at 05:23:33PM +0200, Avi Kivity wrote: > > On 02/23/2011 04:23 PM, Anthony Liguori wrote: > > >On 02/23/2011 07:43 AM, Avi Kivity wrote: > > >>On 02/22/2011 10:56 AM, Kevin Wolf wrote: > > >>>*sigh* > > >>> > > >>>It starts to get annoying, but if you really insist, I can repeat it > > >>>once more: These features that you don't need (this is the correct > > >>>description for what you call "misfeatures") _are_ implemented in a way > > >>>that they don't impact the "normal" case. And they are it today. > > >>> > > >> > > >>Plus, encryption and snapshots can be implemented in a way that > > >>doesn't impact performance more than is reasonable. > > > > > >We're still missing the existence proof of this, but even assuming > > >it existed, > > > > dm-crypt isn't any more complicated, and it's used by default in > > most distributions these days. > > IMHO dm-crypt isn't a generally usable alternative to native built > in encryption in qcow2. It isn't usable at all by non-root. If you > want to use with plain files, then you need to turn the file into > a loopback device and then layer in dm-crypt. It is generally > just a PITA to manage. I wasn't suggesting dm-crypt is a replacement for qcow2 encyption, just that it shows that block-level encryption can be done with reasonable overhead. -- error compiling committee.c: too many arguments to function