Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I suspect I'm a bit offtopic with the site mission, but it seems me more fitting for the question than stackoverflow

i'm in preparing to create a vm with sensible data (personal use, it will be a web+mail+... appliance of sorts), i'd like to protect the data even with cryptography; the final choice have to be cross-platform for the host

basically, I have to choose between guest system-level cryptography (say, dm-crypt or similar) or host level cryptography with truecrypt.

do you think that the "truecrypt-volume contained virtualized disks" approach will hit the i/o performance of the vm badly (and therefore dm-crypt like approaches into the vm would be better), or is it doable?

I'd like to protect all the guest data, not only my personal data, to be able to suspend the vm freely without worrying for the swap partition, etc

share|improve this question
Do you have a Trusted Platform Module (or any other encryption advantage) on the host system? What OS is the host system running? – Joel E Salas Nov 30 '11 at 6:31
What kind of threats are you most woried about? Someone being able to compromise the vm host, or steal the hardware? – Zoredache Nov 30 '11 at 9:09
You know this would be much more on topic at Flagged for a migrate there. – Rory Alsop Nov 30 '11 at 12:04
@RoryAlsop The topic is somewhat gray area, but sufficiently on topic enough for here. – sysadmin1138 Nov 30 '11 at 12:50
@sysadmin1138 - no worries:-) – Rory Alsop Nov 30 '11 at 12:52
up vote 2 down vote accepted

I would have to respectfully disagree with Tim and recommend the use of Truecrypt. Encrypt the host OS and leave the virtual machines unencrypted. Truecrypt is multiplatform and, and in the worst of cases (such as OS failure), you can mount your Truecrypt volume from any supported OS.

This has a couple of advantages:

  • Your VMs will not waste precious CPU/memory resources managing their own encryption
  • The VMs will be encrypted from end-to-end (including swap files) invisibly to the guest OS
  • You get the full advantage of full system encryption

From my experience, the performance hit from Truecrypt is negligible (about 5-10%), and VMware will not suffer a penalty when handling disk I/O in a VMDK.

share|improve this answer
If you're using Linux, use LUKS instead of Truecrypt. – Teddy Nov 30 '11 at 8:34
If it is an appliance - denoting distribution - how is he supposed to do host based encryption? I'm a fan of TrueCrypt myself - I've used it for years - but it did not sound like it is a viable option here. – Tim Brigham Nov 30 '11 at 18:07
Truecrypt can encrypt any part of the stack (not inside the VM): the VM files, a separate Truecrypt "volume" containing the VM files, or the entire OS. The flexibility of it is the appeal. – Joel E Salas Nov 30 '11 at 18:21
I have to clarify that the appliance is definitely for my personal use only, thus I won't need to think what it means to build a completely self contained solution; therefore the truecrypt solution seems appealing, especially if the performance penalty is so limited for real world use cases. thanks a lot to everyone – Unknown Nov 30 '11 at 19:19

You should be looking at full disk encryption of some sort within your guest OS. This will protect your VM while at rest but not when suspended or running.

Host level is better since it will address your suspended state issue but you are forfeiting your cross OS compatibility. It will also most likely be out of your control.

I would suggest looking into VMware ACE. There is a native encryption method available there. There are potential issues with redistribution going this route however.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.