Follow virtual machine encryption best practices to avoid problems later, for example, when you generate a vm-support bundle.

General Best Practices

Follow these general best practices to avoid problems.

  • Do not encrypt any vCenter Server Appliance virtual machines.
  • If your ESXi host crashes, retrieve the support bundle as soon as possible. The host key must be available for generating a support bundle that uses a password, or for decrypting a core dump. If the host is rebooted, it is possible that the host key changes. If that happens, you can no longer generate a support bundle with a password or decrypt core dumps in the support bundle with the host key.
  • Manage KMS cluster names carefully. If the KMS cluster name changes for a KMS that is already in use, a VM that is encrypted with keys from that KMS enters a locked state during power on or register. In that case, remove the KMS from the vCenter Server and add it with the cluster name that you used initially.
  • Do not edit VMX files and VMDK descriptor files. These files contain the encryption bundle. It is possible that your changes make the virtual machine unrecoverable, and that the recovery problem cannot be fixed.
  • The encryption process encrypts data on the host before it is written to storage. Backend storage features such as deduplication and compression might not be effective for encrypted virtual machines. Consider storage tradeoffs when using vSphere Virtual Machine Encryption.
  • Encryption is CPU intensive. AES-NI significantly improves encryption performance. Enable AES-NI in your BIOS.

Best Practices for Encrypted Core Dumps

Follow these best practices to avoid having problems when you want to examine a core dump to diagnose a problem.

  • Establish a policy regarding core dumps. Core dumps are encrypted because they can contain sensitive information such as keys. If you decrypt a core dump, consider it sensitive information. ESXi core dumps might contain keys for the ESXi host and for the virtual machines on it. Consider changing the host key and recrypting encrypted virtual machines after you decrypt a core dump. You can perform both tasks by using the vSphere API.

    See vSphere Virtual Machine Encryption and Core Dumps for details.

  • Always use a password when you collect a vm-support bundle. You can specify the password when you generate the support bundle from the vSphere Web Client or using the vm-support command.

    The password recrypts core dumps that use internal keys to use keys that are based on the password. You can later use the password to decrypt any encrypted core dumps that might be included in the support bundle. Unencrypted core dumps and logs are not affected by using the password dump option.

  • The password that you specify during vm-support bundle creation is not persisted in vSphere components. You are responsible for keeping track of passwords for support bundles.
  • Before you change the host key, generate a vm-support bundle with a password. You can later use the password to access any core dumps that might have been encrypted with the old host key.

Key Lifecycle Management Best Practices

Implement best practices that guarantee KMS availability and monitor keys on the KMS.
  • You are responsible for having policies in place that guarantee KMS availability.

    If the KMS is not available, virtual machine operations that require that vCenter Server request the key from the KMS are not possible. That means running virtual machines continue to run, and you can power on, power off, and reconfigure those virtual machines. However, you cannot relocate the virtual machine to a host that does not have the key information.

    Most KMS solutions include high availability features. You can use the vSphere Web Client or the API to specify a KMS cluster and the associated KMS servers.

  • You are responsible for keeping track of keys and for performing remediation if keys for existing virtual machines are not in the Active state.
    The KMIP standard defines the following states for keys.
    • Pre-Active
    • Active
    • Deactivated
    • Compromised
    • Destroyed
    • Destroyed Compromised

    vSphere Virtual Machine Encryption uses only Active keys for encryption. If a key is Pre-Active, vSphere Virtual Machine Encryption activates it. If the key state is Deactivated, Compromised, Destroyed, Destroyed Compromised, you cannot encrypt a virtual machine or disk with that key.

    For keys that are in other states, virtual machines using those keys continue to work. Whether a clone or migration operation succeeds depends on whether they key is already on the host.
    • If the key is on the destination host, the operation succeeds even if the key is not Active on the KMS.
    • If the required virtual machine and virtual disk keys are not on the destination host, vCenter Server has to fetch the keys from the KMS. If the key state is Deactivated, Compromised, Destroyed, or Destroyed Compromised, vCenter Server displays an error and the operation does not succeed.

    A clone or migration operation succeeds if the key is already on the host. The operation fails if vCenter Server has to pull the keys from the KMS.

    If a key is not Active, perform a rekey operation using the API. See the vSphere Web Services SDK Programming Guide.

Backup and Restore Best Practices

Set up policies on backup and restore operations.
  • Not all backup architectures are supported. See Virtual Machine Encryption Interoperability.
  • Set up policies for restore operations. Because backup is always in cleartext, plan to encrypt virtual machines right after restore is complete. You can specify that the virtual machine is encrypted as part of the restore operation. If possible, encrypt virtual machine as part of the restore process to avoid exposing sensitive information. To change the encryption policy for any disks that are associated with the virtual machine, change the storage policy for the disk.

Performance Best Practices

  • Encryption performance depends on the CPU and storage speed.
  • Encrypting existing virtual machines is more time consuming than encrypting a virtual machine during creation. Encrypt a virtual machine when you create it if possible.

Storage Policy Best Practices

Do not modify the bundled VM Encryption sample storage policy. Instead, clone the policy and edit the clone.
Note: No automated way of returning VM Encryption Policy to its original settings exists.

See the vSphere Storage documentation for details customizing storage policies.