Changing the Hostname on a Production vCenter Server shows all the steps I have used to change the vCenter Server hostname.
Disclaimer: All steps shown here were performed in a lab environment. Before applying them to your environment, make sure to understand everything and, if possible, replicate them in a lab or test environment. We’ll not be responsible for any downtime caused to your environment due to unplanned and untested actions!
During this process, the vCenter Server will be unavailable for some minutes (15 – 20 minutes in my test because all vCenter Server services will be restarted). So, make sure to schedule it during a maintenance window!
About Our Lab Environment
Our lab environment is made by one vCenter Server and two vSAN clusters, as we can see in the following picture:
Software versions:
- vCenter Server: 8.0.3 build 24022515
- ESXi hosts for the cluster “CL-VSAN-ESA”: 8.0.3 build 24585383
- ESXi hosts for the cluster “CL-VSAN-OSA”: 8.0.3 build 24585383
The environment works fine; all devices have entries on our local DNS server. Our vCenter Server has the FQDN “vcsa01.lab.local”:
Planning the Hostname Change
We aim to change the vCenter Server hostname from “vcsa01.lab.local” to “vcsa.lab.local”.
Since we already have an “A” entry on our DNS server pointing to the vCenter Server IP address, we must add a new entry (a “CNAME”, for instance) to ensure the vCenter will be reached by the new hostname:
The DNS “CNAME” record must point to the existing “A” record, as we can see in the following picture:
After that, the “vcsa” hostname must be reached on the network, as we can see in the tests using “ping” and “nslookup” tools:
Furthermore, there are other prerequisites that you need to make sure of, as we can see in the following article:
https://blogs.vmware.com/vsphere/2019/08/changing-your-vcenter-servers-fqdn.html
Note: Our lab environment is simple and does not have external integrations with anything (Active Directory, etc.), so I only mentioned the DNS records point!
Another important consideration is having a valid backup of your vCenter Server. If your vCenter Server is a virtual machine, you can clone or back it up using your backup tool.
Another possibility is to configure a vCenter File-Based Backup. We have written an article about that:
https://dpcvirtualtips.com/creating-a-backup-of-vcenter-data/
To restore a vCenter Server from a File-Based Backup:
https://dpcvirtualtips.com/restoring-a-vcenter-server-through-backup/
Changing the vCenter Server Hostname Through VAMI
The first step is to access the vCenter Server Management Interface (VAMI). In this case, for instance, the URL is:
https://vcsa01.lab.local:5480
Change the vCenter Server FQDN with yours:
Go to “Networking” –>Click on “Edit” under the “Network Settings”:
Change ONLY the hostname and KEEP the domain name value. Click “NEXT” to continue:
from: vcsa01.lab.local –> to: vcsa.lab.local
Type the SSO administrator credentials and click “NEXT”:
Mark the option “I acknowledge that I have…” and click “FINISH”.
Be careful with all instructions under the “Next Steps” section. Take a screenshot of this page and make sure to adjust each point if it hits your environment:
This process will generate new certificates for the vCenter Server (So, the process will generate only managed vCenter Server certificates – it will not do anything with custom certificates):
At the end of the process, a redirection action will occur, redirecting you to the new vCenter Server FQDN:
The message below means that vCenter is reachable by the new hostname/FQDN, but the services are not ready yet. Take some minutes and try to reaccess the vSphere Client:
After some minutes, here we go:
The vCenter Server is available through the new Hostname/FQDN, and all ESXi hosts are connected usually:
Renewing the ESXi Host’s Certificate
This process does not renew the ESXi host’s certificate. So, the next step is to renew each host certificate.
As we can see in the following picture, the host certificate issuer is the old vCenter Server FQDN:
To renew the certificate:
We can follow this process through the vCenter Server “Recent Tasks”:
Afterward, the new FQDN will appear in the Issuer field, as we can see in the following picture:
Additionally, click on “Refresh CA Certificates” to copy the CA certificate to the local ESXi host:
Do the same steps for all ESXi hosts, one at a time!
Post Checking Using the VDT
Afterward, I recommend you run the VDT in your vCenter Server. You can download the tool using the following link:
https://knowledge.broadcom.com/external/article/344917/using-the-vcf-diagnostic-tool-for-vspher.html
Download the file at the end of the page and copy it to the vCenter Server (inside the /root directory, for instance):
Remove the “.zip” with “unzip” and execute the vdt:
unzip vdt-2.0.8-09_18_2024.zip
cd vdt-2.0.8-09_18_2024/
python vdt.pyThis diagnostic tool will not change anything in your vCenter Server. It will just do a lof of tests and give you the results.
In my case, for instance, the following tests did not pass and resulted in a FAIL result:
DNS CHECK FAILED:
IDENTITY SOURCE CHECK FAILED:
To fix the first error (DNS Check), I needed:
- Remove the DNS “CNAME” register “vcsa” that points to DNS “A” register that points to “vcsa01.lab.local”;
- Remove the DNS “A” register that points to “vcsa01.lab.local”;
- Create a new DNS “A” register pointing to the new vCenter Server FQDN “vcsa.lab.local”:
To fix the second error (Identity Source Check), I followed the provided KB:
https://knowledge.broadcom.com/external/article?legacyId=91965
root@vcsa [ ~ ]#python 0685G00001L9dxsQAB__fix_sts_attrs.py
This tool checks for issues with the built in identity source attributes and fixes them.
WARNING! This script makes permanent changes.
Please ensure you have a backup or supported snapshot of this vCenter and all other
vCenters in the ELM group (see https://kb.vmware.com/s/article/85662).
Would you like to continue?[Yy|Nn]: Y
Provide password for administrator@vsphere.local:
[WARNING] Detected that the connection string (ldap://vcsa01.lab.local:389) is incorrect. Setting to ldap://localhost:389
[DONE] Connection string is now: ldap://localhost:389
root@vcsa [ ~ ]#After applying the fix suggested on Broadcom KB, restart all vCenter Server services:
service-control --stop --all && service-control --start --allRun the VDT again 😉
First error fixed:
Second error fixed:
That’s it!
