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
