VM Encryption

ZSphere uses key providers to protect VM runtime state and virtual disk data. VM encryption and disk encryption can be configured separately to protect an entire VM or individual disks.

VM encryption protects memory and GPU runtime state written to disk and protects data in transit during hot migration. Disk encryption protects data stored on virtual disks and in their snapshots. Encrypted resources depend on keys supplied by a key provider. If the key service becomes unavailable, the affected resources cannot operate normally.

VM Encryption and Disk Encryption

Protected Data

VM encryption: Protects VM runtime state after it is written to disk. Hot migration of an encrypted VM always uses encrypted transport.
Disk encryption: Protects data stored on virtual disks. Snapshots created from encrypted disks remain encrypted.

Encryption Configurations

VM encryption and disk encryption can be combined as follows:

Configuration	Description
VM encryption enabled	When you create a VM, encryption is enabled for all disks by default. You can disable encryption for individual disks as needed.
Disk encryption only	If VM encryption is disabled, you can still encrypt one or more individual disks.
Encryption disabled	The VM runtime state and disk data are not protected by the VM encryption feature.

Encryption Keys and How Encryption Works

Key Hierarchy

ZSphere uses a hierarchy of keys to protect encrypted resources:

Data encryption key (DEK): Encrypts VM runtime state or virtual disk data.
Key encryption key (KEK): Is supplied by the key provider and protects the DEK, so the platform does not need to store an unprotected DEK.

Using and Protecting Key Providers

When you create an encrypted resource or change the encryption state of a resource, the platform obtains keys from the default key provider. After an encrypted resource is created, it continues to depend on the key provider and key that protect its DEK.

Keep keys available based on the key provider type:

Standard Key Provider: Maintain connectivity between the platform and the key provider, and keep the key service and associated keys available.
Native Key Provider: Its keys are stored with the platform. Before using a Native Key Provider to create encrypted resources, back it up and store the backup file in a secure location. If the platform fails or must be rebuilt, use the backup to restore the key service. For instructions, see Back Up the Native Key Provider.

If the key provider connection fails, the key service becomes unavailable, or keys are lost, the encrypted resources that depend on the key provider are locked and become unavailable.

Rekeying Encrypted Resources

Changing the default key provider does not automatically update the KEKs used by existing encrypted resources. Administrators can perform a shallow rekey to rotate the KEKs that protect their DEKs or, after changing the default key provider, to protect existing DEKs with new KEKs from the current default key provider. A shallow rekey does not replace the DEKs or re-encrypt the actual data in VMs or disks.

A global rekey covers VMs, disks, disk snapshots, vTPMs, and encrypted VMs and disks in the Recycle Bin.

Encryption Requirements and Limitations

Requirements

Item	Requirement
License	Make sure the platform has a valid Advanced Edition license.
Key provider	A default key provider must be configured, connected, and available.

Configuration and Storage Limitations

Item	Limitation
Changing encryption	Power off an existing VM before enabling or disabling VM encryption or disk encryption. Enabling VM encryption automatically enables encryption for existing disks. Disabling VM encryption does not automatically disable disk encryption; you can change the encryption state of each disk separately. Converting existing data usually takes longer than enabling encryption when the VM is created.
Shared disks	Disk encryption and disk sharing are mutually exclusive. A shared disk cannot be encrypted, and an encrypted disk cannot be configured as a shared disk.
New disks and disk images	When you create a disk or add one from a disk image, disk encryption follows the VM encryption state by default and can be changed as needed.
Existing disks	When you attach an existing disk to a VM, the disk retains its encryption state, which cannot be changed during attachment. The VM encryption state does not change the encryption state of the existing disk.
RDM disks	RDM disks do not support disk encryption and are not automatically encrypted when VM encryption is enabled.
Data storage	An encrypted disk can be created or migrated only on data storage that supports disk encryption. ZHPS distributed storage does not support disk encryption.
Data cleanup	After you change the encryption state of an existing VM or disk, the source data from before the conversion is retained on the Data Cleanup tab of the data storage. Verify that the converted data is usable, and then remove the source data.

Interoperability with Other Features

Operation	Scenario	Requirement or Limitation
Cloning	Clone a VM	If VM encryption is enabled on the source VM, it remains enabled on the cloned VM. Encrypted source disks remain encrypted. Unencrypted source disks remain unencrypted by default and can be encrypted as needed. If VM encryption is enabled on the cloned VM, encryption is enabled by default for its unencrypted disks.
Snapshots	Create a snapshot	A snapshot inherits the encryption state of each disk. Snapshot data created for an encrypted disk remains encrypted. A snapshot does not record the encryption state of VM runtime data.
Snapshots	Create a VM from a snapshot	The VM encryption option follows the current VM encryption state of the source VM. Each disk inherits the encryption state of its corresponding snapshot disk. An encrypted snapshot disk remains encrypted and cannot be decrypted during creation. Encryption can be enabled for an unencrypted snapshot disk as needed.
Backup	Create backup data	When a full or incremental backup is created for an encrypted VM or disk, the corresponding backup data remains encrypted. The default key provider must be available when encrypted backup data is created.
Backup	Synchronize backup data	Backup data for a VM with VM or disk encryption enabled cannot be synchronized to remote backup storage.
Migration	Hot-migrate a VM with VM encryption enabled	Migration traffic encryption is enabled automatically and cannot be disabled, regardless of the disk encryption state.
	Hot-migrate a VM without VM encryption	Migration traffic encryption is disabled by default and can be enabled as needed. Disk encryption alone does not require migration traffic encryption.
	Perform a cold migration that transfers disk data	When the migration interface provides the migration traffic encryption option, it is enabled automatically and cannot be disabled if VM encryption is enabled. Otherwise, it is disabled by default and can be enabled as needed.
	Perform a cold migration that does not transfer VM runtime state or disk data	Migration traffic encryption does not need to be configured. For example, changing only the host of a shut-down VM on shared storage does not transfer disk data.
	Change the data storage of an encrypted disk	An encrypted disk can be migrated only to data storage that supports encryption.
	After migration	The VM and each disk retain their respective encryption states from before migration.
	Perform a batch migration	If any selected VM has VM encryption enabled, migration encryption is enabled for the entire batch and cannot be disabled.
High Availability	Recover a VM through HA	The VM and its disks retain their encryption states after HA. The key provider and keys that protect the resources must remain available.
Templates and Export	Convert to a template	These operations are not supported for VMs that have VM encryption or disk encryption enabled.
	Clone to a template
	Export as an OVA file

PreviousKey Provider Management NextVM Trusted Security