From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42485)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1WPujg-0004GO-Lg
	for qemu-devel@nongnu.org; Tue, 18 Mar 2014 10:11:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1WPuja-0004vH-Ho
	for qemu-devel@nongnu.org; Tue, 18 Mar 2014 10:11:20 -0400
Received: from mx1.redhat.com ([209.132.183.28]:35653)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1WPuja-0004uv-Ab
	for qemu-devel@nongnu.org; Tue, 18 Mar 2014 10:11:14 -0400
Date: Tue, 18 Mar 2014 15:09:50 +0100
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20140318140950.GO4607@noname.str.redhat.com>
References: <EE1A64E628992240A94E2B625745F0167602286166@aplesstripe.dom1.jhuapl.edu>
	<20140318130819.GB7136@stefanha-thinkpad.redhat.com>
	<20140318133044.GF29054@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140318133044.GF29054@redhat.com>
Subject: Re: [Qemu-devel] Adding dmcrypt to QEMU block drivers
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit@irqsave.net>, "Hamilton,
	Peter A." <Peter.Hamilton@jhuapl.edu>, Stefan Hajnoczi <stefanha@gmail.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>, "Coffman,
	Joel M." <Joel.Coffman@jhuapl.edu>

Am 18.03.2014 um 14:30 hat Daniel P. Berrange geschrieben:
> Also, we shouldn't be focusing on QCow2 here. While we're certainly
> aiming to obsolete QCow2's encryption, we should be aiming to cover
> any of the drivers. eg people using the built-in rbd/iscsi/gluster/nfs
> backends want to be able to use encryption too - we don't want to
> force them to abandon the QEMU native block drivers and go to the
> kernel for these network protocols just to use encryption.

I think the part that the qcow2 block driver should be contributing is
just that it can automatically create an encryption layer if the image
file header contains a flag that this new encryption mechanism is used.
This way a similar interface as before could be provided, where the user
basically just says '-hda encrypted.qcow2' and qemu will ask for the
password.

Kevin