The basic idea here is that I want encrypted partitions for my domUs (guests), but not for dom0. The reason for this is that I normally does not have physical access to the machines, so I will need to have the machine boot and start sshd without user interaction.
These notes are from a Debian Squeeze dom0/host, with a single 1TB drive installed. dom0 is not in the LVM. Note that these notes are not XEN nor Debian specific, this is just the solution I went with for running XEN guests in an encrypted LVM on my configuration. You should be able to do similar for pretty much any Linux Distro, with or without XEN.
aptitude install lvm2 cryptsetup
Create partition for LVM volume group (vg)
I use cfdisk for this (curses-interface). Basically you need to choose the free space to use, make it a primary parition. I chose tyoe 8E (Linux LVM) for the drive, but I am not sure if this is necessary. Remember to select write in cfdisk before exiting.
Device Boot Start End Blocks Id System /dev/sda1 * 1 3648 29295616 83 Linux /dev/sda2 3648 3891 1951745 5 Extended /dev/sda3 3891 121601 945510624+ 8e Linux LVM /dev/sda5 3648 3891 1951744 82 Linux swap
At this point I had to reboot to actually be able to do anything with sda3. This might be due to some XEN magic I don't understand yet. If I understand correctly dom0 has access to most hardware, but must be given so through the XEN hypervisor.
Create and unlock an encrypted container
We need to create something called an encrypted container for the LVM, which basically is what makes encryption happen for the LVM
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sda3
You will be asked to give a password, which needs to be remembered/written down. This will be required each time you want to unlock the encrypted LVM (after every boot). Now this container will be locked by default so we will have to open it (you will be asked for the passord):
cryptsetup luksOpen /dev/sda3 crypt
Set up LVM
With the encrypted container we can actually set up/use the LVM
root@moonlight:/home/zerqent# pvcreate /dev/mapper/crypt Physical volume "/dev/mapper/crypt" successfully createdCreate a Volume Group (vg)
root@moonlight:/home/zerqent# vgcreate vg /dev/mapper/crypt Volume group "vg" successfully created
Ready for action
You are now ready to create Logical Volumes (lv)s. Remember that you will have to unlock the lvm after each boot, or if you lock it.
/sbin/cryptsetup luksOpen /dev/sda3 crypt vgscan --mknodes vgchange -ay
Application with XEN
Performance wise the net tells me that XEN guests running on LVM as opposed to images (files) is better. With this setup you will have to unlock the LVM exactly once if dom0 needs to reboot. Alternatives for this setup could be encrypted Volume Groups, encrypted-LVM-in-LVM (e.g. during install of guest you create an encrypted LVM which actually already resides in the LVM exposed by the XEN hypervisor).
Security considerations
What security gain you get from this is somewhat questionable. If Dom0 is compromised and the LVM is unlocked you get none. Also a running system with the LVM unlocked will have to store the encryption key somwhere, so this could be compromised. However if someone should steal your computer I deem it unlikely that they will recover anything from the encrypted LVM. These thought are of course based on the understanding that you do not generate, nor store the key to unlock your encrypted drives on the same computer as the LVM resides.