Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Replacing vCenter Server when vSAN Encryption is configured (76306)

Last Updated: 8/20/2023Categories: How toTotal Views: 4856Language:
Chinese (Simplified)JapaneseEnglish

1 like this article

Subscribe to get an email
newsletter with new updates

1 people found this helpful Please provide article feedback:

Symptoms

After migrating hosts to a new vCenter, the hosts work normally.  However, on reboot, the hosts will show drives as unmounted.

Running the command “vdq -q” from one of the hosts, shows drives as not mounted and are ineligible for use by vSAN. In the UI the devices show as encrypted and locked because the encryption key is not available.

Cause

The issue occurs because the KMS cluster was not added to the new vCenter or it was added under a different KMS Cluster ID.

Impact / Risks

The drives will not become available for vSAN to use until the hosts have reached crypto safe mode.

Resolution

In order to recover from this issue, it is necessary to create a new KMS cluster with the same exact KMS cluster ID as the previous vCenter.
It is imperative that the same KMS cluster ID remains in order for the recovery feature to work. Although the old vCenter is gone, the hosts still have the information and keys from the KMS cluster, after connecting to the same KMS cluster with the same cluster ID, the hosts will be able to retrieve the key (assuming the key still exists and was not deleted). The KMS credentials will be re-applied to all hosts so that hosts can connect to KMS to get the keys.

Since the decommissioned vCenter is no longer available, the KMS cluster ID cannot be retrieved from the vCenter KMS config screen.
In order to obtain the kmip cluster ID, it is necessary to look for such info in the esx.conf file of the hosts.
Open the esx.conf using cat or grep to look at the kmipServer information. Look for kmipClusterId, name(alias), etc. Ensure the KMS cluster on the new vCenter is configured exactly as it was before.

cat /etc/vmware/esx.conf
or
grep “/vsan/kmipServer/” /etc/vmware/esx.conf

/vsan/kmipServer/child[0000]/old = "false"
/vsan/kmipServer/child[0000]/port = "5696"
/vsan/kmipServer/child[0000]/address = "x.x.x.x"
/vsan/kmipServer/child[0000]/name = "HTKC_1.vsanpe.vmware.com"
/vsan/kmipServer/child[0000]/kmipClusterId = "HTKC_KMS_Cluster"
/vsan/kmipServer/child[0000]/kmskey = "HTKC_KMS_Cluster/HTKC_1.vsanpe.vmware.com"
/vsan/kmipServer/child[0003]/kmskey = "HTKC_KMS_Cluster/HTKC_2.vsanpe.vmware.com"
/vsan/kmipServer/child[0003]/kmipClusterId = "HTKC_KMS_Cluster"
/vsan/kmipServer/child[0003]/name = "HTKC_2.vsanpe.vmware.com"
/vsan/kmipServer/child[0003]/address = "x.x.x.x"
/vsan/kmipServer/child[0003]/port = "5696"
/vsan/kmipServer/child[0003]/old = "false"

Notice that the KmipClusterId is “HTKC_KMS_Cluster”. When creating the new KMS cluster in the new vCenter use the same KmipClusterId with the required information. KMS information including port varies by KMS vendor. In this case, HyTrust uses port 5696.

After the KMS cluster has been added to the new vCenter as it was configured in the old vCenter, there is no need for reboots. During reconfiguration, the new credentials will be sent to all hosts and such hosts should reload keys for all disks in a few minutes.
Note: As of ESXi 7.0 we switched from esx.conf to configstorecli. To get the KMS info from a host running 7.0 or higher using a Native Key Provider run the below command:

[root@esxi01:~] configstorecli config current get -c esx -g trusted_infrastructure -k "kms_providers"

For 3rd party KMS run configstorecli config current get -c vsan -g system -k "vsan"|less

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
プロバイダ VDC のリソース プール間でパワーオン状態の仮想マシンを移行すると、「vim.fault.CannotAccessNetwork」エラーが発生する (79005)

KB
•
在引导期间初始化 vSAN 需要很长时间 (2149115)

KB
•
适用于 vRA 8.0.0 HA 环境的修补程序解决了阻止某些服务在数据库故障切换事件后恢复的问题 (76222)

Results 1-4 of 4

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSAN

Related Versions:

Take Our Survey

Support Assistant