28 January 2014

Move SCVMM 2012 R2 Cluster database form one SQL server to another

The only time you can specify your database is during installation.  From then on it is not changeable.  When you have System Center Virtual Machine Manager 2012 R2 configured as a failover cluster things get even more complicated.

There are two common strategies for moving the database. That do not really work for clusters.

The one is changing the registry information regarding the database location. Unfortunately, in a cluster environment those keys are restored when the node is elected.

The second approach is to uninstall VMM while retaining the database and then re-installing and specifying the existing database.  Once again, in a cluster environment you would have to systematically remove all the nodes till the last one, "move the database",and then re-install every node.

 
The only effective way I managed to do this is to forgo the idea of changing the database location in SCVMM.  Instead use a SQL Alias to mask the database move.

Step 1 Get the existing configuration
Open the VMM console
Select Setting
Open Database Connection

From here you can see the current configuration.  It is important to note here that this will not be changed.  It will remain the same.



Step 2 Backup and restore / move the database
Open fail over cluster manager
Stop the SCVMM cluster role.
Start you backup on the existing SQL
Restore your backup on the new SQL

Step 3 Create the alias
Ttart c:\Windows\System32\Cliconfg.exe
Select the Alias tab
Click the Add button
In the server alias specify the current database instance name from Step 1
In the servername specify the new servername and instance
The Pipe name should be auto completed.



Note : This step needs to be completed on each cluster node.  If not the nodes will be pointing to two different databases.

Step 4 Start the SCVMM cluster role
Open fail over cluster manager
Start the SCVMM cluster role.



At this point you should be able to take the old database offline.  I would suggest proper testing to make sure all the nodes are connecting correctly to the new database before permanently removing the old one.