Maybe its during the upgrade from vSphere 4.0 to 4.1 and you require the 64 bit hardware. Maybe you need to upgrade to take advantages of a newer OS and you just don't trust the next next done that Microsoft provides you. Maybe its the fact that you currently have a physical vCenter and you want to take advantage of VMware High Availability and Distributed Resource Scheduler. Or maybe its the complete opposite and you are currently virtualized and you have your reasons to be physical. Whatever your reasons may be, there will more than likely be a time where you as a VI admin will want or have to migrate your vCenter to a new server. In my case, it was option number 4.
We had been running a virtualized vCenter ever since our upgrade to vSphere 4, however with the addition of the Distributed Virtual Switch, along with more and more third party applications depending on vCenter, coupled with a failure that left me unable to assign a vm to a network I just thought it was time to move our vCenter Server outside of the cluster that it was controlling. The decision to go physical was purely an overkill, but i wanted to have my vCenter completely disconnected from the san fabrics and interconnects that are currently the interworkings of our i/o flowing in and out of our hosts. I had read about the recommendation of management clusters, but the costs of building that would for sure outweigh the advantages of having it virtualized. Also, this will give us a central spot to house our PowerCli scripts and also run our UPS shutdown scripts from. So, physical it is, and here is my plan to get there. It wouldnt have been much of a concern but i wanted to have a solution where the dvSwitches would continue to function, and where i wouldnt need to go and touch every host afterwards. So, assigning this new physical vCenter the same name and same IP was a key step. Since i wanted to ensure a smooth transition i ran this one through the lab first using these steps. So here is what i had. vCenter1 (the current active vCenter) and vCenter2 (the new vCenter).
1. Get everything that you need (vCenter installation, 64 bit sql native client, sysprep files, etc). If vCenter1 is virtualized be sure to take note on which host its running on as you will need to disable or disconnect its network later on.
2. When you are ready to go stop the vCenter service on vCenter1.
3. Now we need to disconnect or disable the network on vCenter1.
4. Delete the current computer account for vCenter1 from active directory. I assume you could also just rename it, i just chose to delete the account.
5. Now lets move over to vCenter2 and do a few things. Rename this machine to vCentre1 and also give it the same ip as vCenter1. This should ensure that we don't have to ssh into each host after the upgrade and touch the hosts file.
6. Now just complete the installation of vCenter on vCenter2 which is the now vCenter1. (Confused yet?). Note – when asked about the database be sure to select to use the existing db, otherwise you can kiss all your hard work goodbye.
Thats all, you should be able to connect to your new vCenter instance using the same name or IP as you always have. You may have to reconnect your hosts however, as a new password for the vpxuser would have been generated with the new install and the hosts and vCenter will be out of sync. Thats as simple as right clicking your host, selecting connect and providing root credentials though. There you have it, a brand new vCenter! While your at it you might as well defragment your vCenter Server database as well to give it that snappy new feeling again. Also, there is a KB article which takes you through some of the steps above here. As always if you notice anything that I'm lacking or if I'm performing actions that will cause the market to crash please comment and let me know.
