Starting with vSphere 6.5, customers can take advantage of virtual machine encryption. This section describes how to design backup and restore to handle VM encryption.
Encryption protects sensitive parts of a VM and some or all of its virtual disks. The vCenter Server retrieves keys from a key management server and pushes them to ESXi hosts, which use the keys to encrypt virtual disk data, NVRAM, portions of the VMX file, and so forth. See the vSphere Security manual for details.
To back up encrypted virtual disks, VDDK obtains the encryption keys and decrypts virtual disk data before copying to backup media, so virtual disk data on backup media are in the clear (not encrypted). VMware recommends that backup agents use their own encryption to protect data on backup media.
Backup of encrypted disks is supported with NBDSSL and HotAdd transport modes, but not supported with SAN transport. To back up encrypted virtual disks using HotAdd, the backup proxy VM must have been encrypted as well. Both NBDSSL backup and HotAdd backup require Cryptographer.Access permission. HotAdd backup requires Cryptographer.AddDisk also.
Application quiesced snapshots are not supported for encrypted VMs. Use file-system quiescing instead. The snapshot manifest file will contain only a dummy backup.xml file.
Encrypted Virtual Disks
When customers restore virtual disks that were encrypted at backup time, they likely want them to remain encrypted after restore. If a disk was encrypted when it was backed up, the backup agent can remember the storage policy and apply it to the restored disk. If that storage policy no longer exists in the system, the backup agent could ask the administrator what policy to apply for encrypted disks, or use the sample VM encryption storage policy. Optionally the backup agent can remember a disk’s key ID and provide it at restore time, which will result in the restored disk using the same key as the original disk. If not specified, vCenter Server gets a new key from the key server.
Recommendations for VM Home
When a VM is encrypted, its VMX configuration file contains portions that are encrypted, and the entire NVRAM file is encrypted. To completely recover a VM from backups, the NVRAM file must be restored, and two additional properties from the VirtualMachine object's configuration must be restored: (1) the encryption key identifier, found in the VirtualMachine ConfigInfo.keyId property, and (2) an encrypted blob containing VM secrets, called the encryption.bundle, found in the VirtualMachine ConfigInfo.extraConfig list.
VMware recommends against directly copying the entire VMX configuration file, but instead using the PropertyCollector to keep a record of configuration structures as documented earlier in this chapter. When a VM is saved, the backup agent should include the ConfigInfo.keyId, the encryption.bundle from ConfigInfo.extraConfig, and the current storage policy.
Later when the backup is restored, these values should be provided in the new VirtualMachine ConfigSpec. This will ensure that the recovered VM metadata files are protected with the same key as the original VM. If a VM is restored to a vCenter Server with key server access, the VM will boot. However if the vCenter Server lacks key server access, the VM will not power on after restore, because vCenter Server cannot push encryption keys to its ESXi host.
The NVRAM file can be handled as it was in previous releases, using HTTP download and upload, but without saving the additional ConfigInfo properties described above, the NVRAM will be unusable. This is because it is encrypted with the key that is found in the encryption.bundle, which is in turn sealed with the key identified by ConfigInfo.keyId. The recovered VM must be created in a vCenter Server that has access to the same key server as the original, or a replicated key server instance with the same cluster name.
What If Something Fails
If the ConfigInfo.keyId and encryption.bundle were not saved, it will be impossible to encrypt the recovered VM using its original encryption keys. However the VM may be encrypted with new keys from the key server. If the NVRAM file was saved, it is unusable without the original ConfigInfo.keyId and encryption.bundle information. If the NVRAM file was not saved, or unusable, a generic one can be used instead. After NVRAM is lost and regenerated, UEFI enabled VMs may require Secure Boot to be reconfigured, or the boot disk to be reconfigured.
If the vCenter Server has lost access to the original keys from the key server, then a restore operation may remove the encryption.bundle from ConfigInfo.extraConfig and specify only a VM encryption storage policy for the VM and its disks. Again this will cause any data present in the NVRAM to be unusable.
