Here I collect some blog posts with vCenter key provider configuration recommendations:
- If you plan to rekey your vSphere-encrypted virtual machines, you should understand and prepare for the possibility that they may be unexpectedly rebooted
- If you have intermittent connectivity alerts for your key provider, you should investigate whether the vCenter trust store holds expired certificates.
- For various reasons you should consider configuring vCenter to trust your KMIP server’s CA certificate instead of end-entity certificate
- By doing this you will not have to reconfigure trust as frequently, nor will you need to purge expired keys from your trust store as frequently
- This also corrects rare situations where the end-entity certificates for your KMIP server may vary from time to time (e.g., if there are several servers with differing certificates behind a load balancer)
- If your attempt to make your key provider trust vCenter fails, it may be because you used an older vCenter certificate or because you encountered a vCenter UI bug and copied the wrong certificate.
- If you encounter unexpected “failure to decrypt” errors when migrating encrypted VMs, starting them, or creating a snapshot, you should check whether you have upgraded to vCenter 7.0u3o or higher.
- You should be aware that VMware purposely leaks keys as objects are rekeyed or deleted, and plan to identify and cleanup these keys when they are no longer needed.
And here are some additional VMware encryption resources:
full◦valence 