Two types of keys are used for VM encryption:
• Data encryption key (DEK): The ESXi host generates and uses internal keys to encrypt VMs and disks. These XTS-AES-256 keys are used as DEKs.
• Key encryption key (KEK): The vCenter Server instance requests AES-256 keys from the KMS. vCenter Server stores only the ID of each KEK, but not the key itself.
The vCenter Server system transfers VM KEKs to an ESXi host when the host requires a key. The ESXi host uses the KEK to encrypt the DEK, and it stores the encrypted internal key on disk. The ESXi host does not store the KEK on disk. If a host reboots, the vCenter Server instance requests the KEK with the corresponding ID from the KMS and makes it available to the ESXi host. The ESXi host can then decrypt the DEKs as needed. Figure 1 illustrates the roles of the KEKs and DEKs.

Initially the ESXi hosts do not have the necessary keys to perform cryptographic operations like encrypting and
decrypting guest data. vCenter Server obtains the keys from the KMS and then pushes them down to the hosts.
These keys are called key encryption keys (KEK). The host generates the data encryption keys (DEK), which are Managed VM Keys
Managed VM Key IDs
Encrypted VM
ESXi
vCenter Server
Managed VM Keys
Managed VM Keys
Third party key management servers (KMS) vSphere Managed VM keys protect internal encryption keys then used for encrypting and decrypting virtual machine files. KEKs are used to encrypt the DEKs, and these encrypted DEKs are stored in configuration files. Once encrypted, the KEK for the virtual machine needs to be in ESXi memory for the VM to be powered on. If for some reason the ESXi host is power cycled or the encrypted virtual machine is unregistered and then re-registered, vCenter gets the KEK from KMS again and pushes it to ESXi. KEKs are stored only in the KMS where they are generated and not persisted anywhere on vSphere. KMS should be highly available, or keys should be replicated between multiple KMS instances added to the same KMS cluster for accessibility of KEKs.

Если вцентр недоступен и хост ребутнулся - хост не получит ключ расшифровки, вроде так

ага. When a host reboots, it does not mount its disk groups until it receives the KEK. This process can take several minutes or longer to complete. You can monitor the status of the disk groups in the vSAN health service, under Physical disks > Software state health.

хотя не факт

И помнится мне есть рекомендация не размещать вцентр на всане, который зашифрован через этот же вцентр

рекомендация - не держать KMS на шифрованном кластере

точно

с vCenter как-то все не так однозначно. а тем более с Native KMS - про него вообще ничего пока не знаю

Native KMS не включится пока его не забэкапить

но т.к. KMS все равно надо где-то держать снаружи, то я бы и vcenter держал там же

ставите пароль, им шифруется .p12 файл с KMS, который скачивается на комп

только после этой процедуры вцентр позволит начать использовать Native KMS

Мы держим реплицирующийся KMS в двух ЦОДах в разных странах. Стоимость просто копеечная - что-то вроде 1.5 к долларов perpetual

Do not encrypt any vCenter Server appliance virtual machines.

А какой вендор кмс если не секрет?

Dell

я имею в виду кмс аплианс какои?