I think CPU-load should only be a secondary consideration. On the placement of dm-crypt, my intuition would be to place it as close to the storage as possible as it works on sector layer, and regard DRBD as sort-of part of the buffer-cache. I may be wrong. Milan is the person that should know. An other aspect is that when placing encryption above BRDB, then the traffic over the network is also encrypted. To me,it does not make a lot of sense to encrypt data on disk, but put the same data unencrypted over a network, even if it is a physically separated network. So with dm-crypt below DRBD, you need to encrypt the data 3 times: 1x local 1x transport and 1x remote, while with dm-crypt above BRDB, you only need to encrypt once. Should the both placents be fine, then definitely place it above. Mirroring a dm-crypt or LUKS container should not cause security problems in itself, two identical containers with the same key(s) should in fact be a tiny bit more secure than two containers with different keys and the same data. (with tiny = does not matter in practice). And with link encryption in addition, you need to trust 2 mechanisms, namely the link encryption in addition. That does increase the attack surface considerably. On the migration issue, I do not understand the question. What is your concern here? Arno On Wed, Dec 07, 2011 at 01:30:37PM +0100, Berengar Lehr wrote: > We want to use LVM, dm-crypt and DRBD in a 2-machine setup for KVM. > > We think, a proper setup could be something like this (dm-crypt below DRBD): > > > ?? ??Machine 1 ?? ?? ?? ?? ?? ?? ?? Machine 2 > > ?? ?? ?? KVM ??-> -> -> -> -> -> ??KVM > ?? ?? ?? ??| ?? (live migration) ?? ??. > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? . > ?? ?? ?? DRBD - - - - - - - - - DRBD > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | > ?? ?? ?? LVM ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? LVM > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | > ?? ?? dm-crypt ?? ?? ?? ?? ?? ?? ?? ??dm-crypt > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | > ??Disk/Partition ?? ?? ?? ?? ??Disk/Partition > > The KVM guest machines should run on machine 1. Live migration to > machine 2 should be supported. > > Using this setup, every write to DRBD would be (independently) crypted > on both machines, > leading to additional (unnecessary?) cpu load on machine 2 before live > migrating, and additional > cpu load on machine 1 after live migration. > > Could these additional cpu loads be avoided using a setup like this > (dm-crypt in top of DRBD): > > > ?? ??Machine 1 ?? ?? ?? ?? ?? ?? ?? Machine 2 > > ?? ?? ?? KVM ??-> -> -> -> -> -> ??KVM > ?? ?? ?? ??| ?? (live migration) ?? ??. > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? .(b) > ?? ?? dm-crypt ?? ?? ?? ?? ?? ?? ?? ??dm-crypt > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |(a) > ?? ?? ?? DRBD - - - - - - - - - DRBD > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | > ?? ?? ?? LVM ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? LVM > ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | > ??Disk/Partition ?? ?? ?? ?? ??Disk/Partition > > In this setup, dm-crypt runs on both machines, too, but is not used on > machine 2 until KVM > guests send write-requests after the live migration. So crypting is > done only by one machine > at every time point. > > Is such a setup safe and stable? > > What about caching at points (a) or (b) on machine 2? > Can KVM read cached, outdated data from dm-crypt after live migration? > > Is there a workaround? > > Thank You > B. Lehr & M. M??ller > > -- > Mate ist gesunder Schlaf in Halbliterflaschen > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
