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

General Best Practices

To avoid problems, follow these general best practices.

  • Do not encrypt any vCenter Server appliance virtual machines.
  • If your ESXi host fails, 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 key provider names carefully. If the key provider name changes for a key server that is already in use, a VM that is encrypted with keys from that key server enters a locked state during power-on or register. In that case, remove the key server from the vCenter Server and add it with the key provider 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 vSphere Virtual Machine Encryption process encrypts data on the host before writing the data to storage. The effectiveness of back-end storage features such as deduplication, compression, replication, and so on, might be affected when encrypting virtual machines in this manner.
  • If you use multiple layers of encryption, for example, vSphere Virtual Machine Encryption and in-guest encryption (BitLocker, dm-crypt, and so on), overall virtual machine performance might be affected, because the encryption processes use additional CPU and memory resources.
  • Ensure that replicated copies of virtual machines encrypted with vSphere Virtual Machine Encryption have access to the encryption keys at the recovery site. For standard key providers, this is handled as part of the design of the Key Management System, outside of vSphere. For vSphere Native Key Provider, ensure that a backup copy of the Native Key Provider key exists and is protected against loss. For more information, see Back up a vSphere Native Key Provider.
  • 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 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 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 key server availability and monitor keys on the key server.
  • You are responsible for having policies in place that guarantee key server availability.

    If the key server is not available, virtual machine operations that require that vCenter Server request the key from the key server 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 key server solutions include high availability features. You can use the vSphere Client or the API to specify a key provider and the associated key servers.

    Note: Starting in version 7.0 Update 2, encrypted virtual machines and virtual TPMs can continue to function even when the key server is temporarily offline or unavailable. The ESXi hosts can persist the encryption keys to continue encryption and vTPM operations. See Key Persistence Overview.
  • 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 key server.
    • If the required virtual machine and virtual disk keys are not on the destination host, vCenter Server has to fetch the keys from the key server. 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 key server.

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

  • Develop key rotation policies so that keys are retired and rolled over after a specific time.
    • Trusted key provider: Change the primary key of a trusted key provider.
    • vSphere Native Key Provider: Change the key_id of a vSphere Native Key Provider.

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 finished. 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.
  • Because the VM home files are encrypted, ensure that the encryption keys are available at the time of a restore.

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.

Removing Encryption Keys Best Practices

To ensure that encryption keys are removed from a cluster, after deleting, unregistering, or moving the encrypted virtual machine to another vCenter Server, reboot the ESXi hosts in the cluster.