More and more people are starting to ask me what the difference is between VMCrypt aka VM Encryption and the beta feature we announced not to long ago called vSAN Encryption. (Note, we announced a beta, no promises were made around dates or actual releases or releasing of the feature.) Both sounds very much the same and essential both end up encrypting the VM but there is a big difference in terms of how it is implemented. There are advantages and disadvantages to both solutions. Lets look at VM Encryption first.
VM Encryption is implemented through VAIO (vSphere APIs for IO Filters). The VAIO framework allows a filter driver to do “things” to/with the IO that a VM sends down to a device. One of these things is encryption. Now before I continue, take a look at this picture of where the filter driver sits.
As you can see the filter driver is implemented in the User World and the action against the IO is taken at the top level. If this for instance is encryption then any data send across the wire is already encrypted. Great in terms of security of course. And all of this can be enabled through policy. Simply create the policy, select the VM or VMDK you want to encrypt and there you go. So if it is that awesome, why vSAN Encryption?
Well the problem is that all IO is encrypted at the top level. This means that it is received in the vSAN write buffer fully encrypted, then the data at some point needs to be destaged and is deduplicated and compressed (in all-flash). As you can imagine, encrypted blocks do not dedupe (or compress) well. As such in an all-flash environment with deduplication and compression enabled any VM that has VM Encryption through VAIO enabled will not provide any space savings.
With vSAN Encryption this will be different. The way it will work is that it will provide “encryption at rest”. The data travels to the destination unencrypted then when it reaches its destination it is written encrypted to the cache tier, then it is decrypted before it is destaged, and it will be encrypted after it is deduplicated and/or compressed again. This means that you will benefit from space saving functionality, however encryption in this case is a cluster wide option, which means that every VM will be encrypted, which may not be desirable.
So in short:
- VM Encryption (VAIO)
- Policy based (enable per VM)
- Data travels encrypted
- No/near zero dedupe
- vSAN Encryption
- Enabled on a cluster level
- Data travels unencrypted, but it is written encrypted to the cache layer
- Full compatibility with vSAN data services
I hope that clarifies why we announced the beta of vSAN Encryption and what the difference is with VM Encryption that is part of vSphere 6.5.
francisdaly2014 says
great explanation
John Nicholson says
Also of note, compression doesn’t work well on Encrypted blocks either (high level of entropy).
Kiran says
Great explanation. If I am using IO Filter and vSAN AF together, which method of encryption would be efficient/recommended in terms of CPU utilization and response time. (total VMs cluster wide encryption is desired).
Duncan Epping says
depends if you need all VMs encrypted or not…
Fariaz Diloo says
Vsan encryption seems promising , is it a full flash option only ?
Duncan Epping says
no, will also be for hybrid
Jab says
Hello, is there a release date for 6.5 ?
Thanks
Nicole D. says
Perfect that was the explaination i was looking for. THX
Aernoud says
Thanks, made it very clear without getting too technical (so I can understand)….
Tom says
Hello, great read!
Just to get a full understanding, does this feature mean that if I log onto the VI, I cannot ‘browse and grab’ an encrypted VMDK ? Additionally will this feature prevent me from being able to mount the encrypted VMDK into a new VM? OR is encryption in this instance the case whereby the data is simply scrambled on disk thus unreadable?
Thanks
Jon Hope says
Duncan is there a scheduled release for VSAN encryption?