Changing the IP of a vCenter Server 5.1 system – Part 1 – The easy way
A couple of weeks back I had a post on changing the hostname of a vCenter server system. Today I am going to look how an IP change will go. The system is very small with a local database installed. VUM is also installed on the same machine. All web based services are working fine.
None of my certificates do actually include an IP address, forward and reverse DNS are setup correctly though and my domain controller is multi homed to keep the setup small.
The domain controller also has the “Routing and Remote Access” role installed and serves as the default router in the setup so I don’t need to do any changes to the connected host.
The last thing I checked was that this time we actually do have a hardware status on the virtual ESXi to compare if this is still the same afterwards.
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.
First step is actually stopping all services and changing the IP address of the vCenter server system. We are going from 192.168.0.10 to 172.16.0.10. This is followed by a reboot of the system. The first test we are going to do is a ping from the host which is successful (after turning off the blocking in the Windows Firewall). Even though the host does still have the old vCenter Server IP in the vpxa.cfg it won’t disconnect as we see later on.
The system boots up just fine like expected and Windows did accept the IP change without any further issues.
Logging into vCenter server the hardware status looks actually good as well but we can see the Update Manager tab is missing now.
So let’s see why the Update Manager plugin won’t connect anymore, which leads us to the vCenter Service Health status and gives us the clue that the addon actually registered with the IP address instead of the host name.
This is easily fixed though using the Update Manager Utility.
One service restart later we get the following picture which completes our little IP change procedure pretty successfully. And just to prove the point this time we have a look at the service status using the Web Client to demonstrate that it did not brake during the procedure as well.
This part was called “easy” because I did not introduce any dependencies on the IP in the certificates which I will do in a later post to see if the procedure is as smooth and easy as this one was.