Changing the host name of vCenter Server 5.5 without reinstalling
And another twitter request that leads up to some experimenting of what you can do without relying on the installer.
Anyone renamed a vCenter 5.5 installation?
— Jason Nash (@TheJasonNash) 28. Mai 2014
Challenge accepted. The victim VC will be my own lab environment VC so this better works in the end. Additional information was provided by Jason which would make this procedure possible, the vCenter Server was a self contained instance without running any dependencies from the upper stack.
Disclaimer: This is not a tested or officially approved procedure by VMware at any means, use at your own risks, don’t come to me complaining if everything breaks, DO A BACKUP! The proper way would be a reinstall of the binary packages against existing databases.
As I am working in the German Language Support team my vCenter is a German install, I tried to get as much as possible in English but most of it should be self evident even if the language is not English on the screenshots.
My starting point is the most recent vCenter Server 5.5 U1a install which is called VC.cork.local and resides in my local AD domain on an internal network and has 1 leg into the outer world for my lab hosts. This outer legs uses DHCP and therefore the hosts have static hosts files implemented to resolves the IP in case I need to power down my VC and lose the lease (which happens quite often over the weekend).
All the steps done in this article refer to the internal network adapter.
Before we can rename the actual machine we will need to create new certificates that are valid for the new host name for each and every service installed on that box. As these intermediate certificates also need to contain the old host name to work before we rename the machine we cannot simply use the SSL automation tool to do everything but need to step in a bit. So the first step is still to create all the requests and config files. Then the config file needs to be edited and the request needs to be recreated (with or without a new key, I am going with a new key here). One could also simply have created the config files without even touching the SSL automation tool.
I semi automated the request creation process after editing the configuration files, early draft of the batch file can be found in the picture below.
The next steps are no different from replacing vCenter Server certificates on a normal box, so business as usual.
At this point we are good to rename the system and do the subsequent reboot for the change to take effect. As a result of this my vCenter Server failed to start. A quick look into the log made the problem apparent.
I am using a local SQL database and the ODBC connection still referred to the old host name. Easy enough to fix, simply change the ODBC connection string to the new host name and also do the same for the 32bit ODBC if Update Manager is being used, as it will have the same issue. This would not have happened if I used an external DB server.
The vCenter database is not only accessed by that ODBC connection string but also by a JDBC connection which is used by the Management Webservices. So better change that one as well. The file is located in C:\ProgramData\VMware\VMware Virtualcenter.
The next 2 steps are correcting some of the vCenter Server internal settings.
This “repairs” the leaf node name in the vSphere Client and vCenter Server Web Client for this VC.
This basically repairs the Management Webservices connections to a certain degree. At this point in time I actually felt confident enough to actually remove DNS configuration for the old name and try a reboot. Well vCenter wasn’t too happy about it though and got into a restart loop which was caused by it not being able to contact SSO (wouldn’t have happened with an external SSO).
So this was an oversight in the actual vCenter Server settings menu, as this would have been listed there, so how do we change this configuration now when vCenter is not able to start? We could put back the DNS alias for the old host name again but that would be boring, so let’s change the actual config file this setting is mapped in.
After this change vCenter Server would start without issues and even the Management Webservices would be working as I could see the vCenter Health Status, but there is still quite a bit of work to be done to get rid of all that red and yellow (well the yellow actually can be ignored as it is a false alarm caused by a recent reboot).
Let’s take a logical approach here. Right now the “broken” services are Inventory Service, Profile Driven Storage Service, Storage Monitoring Service, Update Manager and Auto Deploy. I figured by fixing the Inventory Service most of the red will be gone, as the SMS and SPS do actually depend on the Inventory Service for successful logins. So let’s get this one to green first. The following 3 screenshots show the config files that need to be changed to actually fix the issue.
So this gives us the nice green tick box but is actually misleading as the Web Client login and the vSphere Client search function are still broken.
The Web Client error message gives us a valuable hint though. It looks like the SSO registration for everything is now broken as well due to the host name change. So first try is to change the only file mentioning this URL on the file system but it was a failure.
So let’s dig a little deeper into the SSO configuration. Every service has a Solution user in SSO that is registered with a certificate, this should be perfectly fine already as we replaced the certs for each service prior to renaming the machine. Additionally most services do have a service endpoint URL in the SSO configuration. This does not get updated when replacing certificates. So let’s try and list them.
C:\Program Files\VMware\Infrastructure\VMware\CIS\vmware-sso\ssolscli.cmd listServices https://vcenter.cork.local:7444/lookupservice/sdk
This should list all endpoints registered into my local SSO but instead I got this lovely Java error stack complaining that the admin service URL cannot be resolved.
So let’s put the DNS alias back in place for just a second and confirm that this is the case for every service endpoint.
So how can we fix this? One way would be using the ssolscli.cmd with the updateService namespace, but I am kinda too lazy to do that at this point. As we can also connect using jxplorer to the SSO to edit the configuration I chose that route. Please be careful though as the slightest mistake can completely break the SSO configuration altogether.
Once we are it is easy enough to find the endpoints in the tree and to edit the URLs for each.
We can confirm the fix pretty easy by invoking a search and trying to login into the Web Client which both succeed now.
This leaves Update Manager and Autodeploy. Let’s fix Update Manager first. This is simply done by reregistering it to vCenter Server using the Update Manager utility.
The steps to actually fix Auto Deploy are basically the same and also described in the following KB article.
It’s editing the configuration file and unregistering and reregistering the Auto Deploy extension in vCenter Server.
I also have the Authentication Proxy installed but this would not need any reconfiguration as it needs to be installed by using the IP address for the hostname as the service does not start otherwise.
This should actually be everything that needs to be done. I rebooted the machine once more and sure everything is now green with the Web Client and every default plugin working again and the old host name being thrown out of the DNS settings.
The last step that is needed is to change the host names in the registry in HKLM/Software/VMware, Inc. to reflect the new system name so that you don’t get screwed by upgrades.
If you want anything gone that could even remind you of the old host name you would be looking to replace certificates once more with ones that do not contain the old host name anymore which I will do eventually in a later blog post as well to test the vCert Manager certificate replacement options.