Migrating vCenter Server 5.5 from Server 2008 R2 to Server 2012 R2
I got a request from one of our Technical Account Managers last week as one of his customers wanted to migrate vCenter Server 5.5 from a physical machine to a virtual machine. During that move the operating system should also change.
VMware actually does have a kb article on how to achieve this but it seems to be only validated up to version 5.0.
Since SSO was introduced in version 5.1 the procedure should take that into account and therefore will change slightly.
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 first thing that needs to be defined is the actual environment.
- The database (SQL 2008 64 bit SP3) is co-located with vCenter Server and this will stay the same
- The IP address will stay the same
- The host name in Active Directory will change
- SSO and Web Client are already virtualized and will be re-used
- No storage profiles or vSphere Web Client tags will be needed to be carried over
- No custom roles will be needed to be carried over
First we need to check the database supportability stance from a Microsoft point of view on Windows Server 2012 R2.
SQL Server 2008 SP3 would actually be supported on Windows Server 2012 R2 according to that kb.
Checking the VMware side though we can see that SQL Server 2008 SP 3 is actually not supported for vCenter Server 5.5.
This leaves the customer with the choice of SQL Server 2008 R2 or SQL Server 2012. They need to be on SP2 or SP1 respectively to be supported by Microsoft though, so essentially only two choices here. The actual one should not matter too much as both would support Failover Clustering which is supported with vCenter Server 5.5. Always On functionality is still not officially supported with vCenter Server 5.5 (even though I personally have seen customers use it without any reported issues).
The migration of the actual database is also described in a VMware kb article (which points out versions up to 5.1 but the procedure should not be affected at all for 5.5 as only changes in the schema have been made but not too much else).
As we will reinstall vCenter Server on the target system we will deviate a bit on this though.
First we copy the Virtual Center Server SSL certificate folder (The customer already does have the new FQDN in the SAN field as they used to have vCenter Server Heartbeat before, if not you would be looking into deploying new certs on the original system that include both names and then a final replacement on the destination system after everything is installed for certs only containing the destination names and IPs) and the database backup to a different machine, as we need to completely shut down the original server to avoid duplicate IPs.
The next thing to do is to install the new vCenter Server and the SQL Server 2012. For this lab I will just just pretty much defaults on everything.
I activated the IPv4 TCP/IP settings in the SQL Server Configuration Manager, restarted the service and then restored the original vCenter Server database.
As SSO and the vSphere Web Client are already virtualized the only thing left is to install Inventory Service and vCenter Server against that same SSO using the restored database.
It is also advisable to use ssolscli to clean up the old solution users and service endpoints (I would use the Web Client for the solution users though, as it is far more easier to do over a GUI).
An example on how to do that can be found in the following kb.
If you remove the solution users and service endpoints prior to installing the new VC instance less confusion is possible on which entries exactly to get rid of.
Even if you want to keep the solution users for whatever reason it might be still advisable to remove the service endpoints as these can slow down the login process quite a bit when no service is listening behind them anymore.
In case you haven’t done so you might also need to install .NET 3.5 as a feature to be able to install vCenter Server.
vCenter Server should also be pretty straight forward but needs one additional step before it can be done if you do not want to see the following error.
The installer also seems to have pulled the custom roles data back from the binary AD LDS backup from the database (VPX_BINARY) which I find to be pretty cool.
All cluster / resource pool / vApp information and settings have also been kept and all hosts were still connected. My storage profiles were gone as expected. My customization spec was still existing but despite having used the same private key and public cert for the vCenter Server I was getting the following message which kinda surprised me as the hosts did not disconnect.
Scheduled tasks and host profiles have also been kept.
After vCenter Server is installed you will also need to make one more change to the database. The restore actually did carry over all stored procedures but the SQL jobs are gone.
The files to recreate them can be found in C:\Program Files\VMware\Infrastructure\VirtualCenter Server\sql and a kb article describing the procedure can be found below.
The only thing left to do now is to remove the old vCenter Server host name from the DNS setup and the migration is complete (depending on your host’s vpxa configuration it might disconnect .
I did not move Update Manager for this PoC but the process would be pretty similar actually. If you are moving the database for Update Manager as well instead of starting with a clean slate be sure to also move the repository, especially when you have custom ISOs or patches uploaded to Update Manager, as otherwise scans and remediation will fail, as it can not find these patches on the file system.