Followed this KB article on migrating an existing SRM instance to a new server. A few hiccups, however.
This SRM implementation was using EMC RecoverPoint. To get the RecoverPoint SRA installed, SRM had to already be installed. However, couldn’t install SRM because it’s services would not start since the existing database it was connecting to expected the SRA to be available. Resolution was along the lines of the following:
*Make sure you have a backup copy of the database or use a temporary database (I used backup/restore method as opposed to a temp DB)*
- Make sure the Site Recovery Manager Server service on the old server is stopped.
- Backup the known good copy of the database
- Run the SRM installer on the new 64-bit server, when prompted select the DSN (you created a 32-bit DSN, right?) to the existing database (choose to maintain the contents / do not overwrite)
- Complete the installer
- This is where it got funky. The Site Recovery Manager Server service fails to start so checked the logs located at %ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Site Recovery Manager\Logs (open the current .log file)
- The prompt at the installer will have the Retry and Cancel options. If you choose Cancel it will rollback the install and leave the database in an unhealthy state – this is where our backup is going to come in handy.
- Once the rollback completes, start the install again and complete the exact same steps (this time it will not prompt you about overwriting the existing database as it doesn’t believe the database has vaild data). Allow the install to go through – it will finish this successfully this time.
- Now, install the EMC RecoverPoint SRA. It will install successfully since SRM is now installed.
- Uninstall SRM (just step through the uninstaller, don’t check the box about removing the database contents – not that it will matter as we will be restoring our known good copy anyway).
- Restore the backup of the database choosing to overwrite the database.
- Install SRM and this time it will prompt regarding the existing database – select to use the existing database.
- The installer will still fail this time as well, but checked the log this time and found the following:
[2010-08-26 15:34:40.560 03192 verbose 'PrimarySanProvider'] Loading Array Manager 'array-manager-4353' from DB object
[2010-08-26 15:34:40.560 03192 warning 'DrServiceInstance'] Initializing service content: (dr.san.fault.ManagementSystemNotFound) {
dynamicType = ,
faultCause = (vmodl.MethodFault) null,
name = "C:/Program Files/VMware/VMware vCenter Site Recovery Manager/scripts/SAN/array-type-recoverpoint",
msg = "",
}
[2010-08-26 15:34:40.560 03192 error 'App'] Application error: dr.san.fault.ManagementSystemNotFound. Shutting down ...
[2010-08-26 15:34:40.560 01788 info 'App'] [serviceWin32,421] vmware-dr service stopped
- The problem here is that the old server was 32-bit windows and therefore installed everything to C:\Program Files\… but our new server is 64-bit and SRM installs to C:\Program Files (x86)\…
- The array manager script path is actually stored in the database. Find the table [pds_arraymanagere] and update the field [scriptpath] to reflect the correct (x86) directory.
- Hit Retry and the service should start correctly.
Still needed to re-pair the sites in SRM but this was the biggest hurdle in migrating the server. Also, reading that process back, the whole thing could have been done in a few different ways.Anyway, this was a bit of a worst case scenario but ultimately it worked out well.
Note: This KB article does exist, bubt it is for two specific scenarios as hihlighted in the article, not this situation
Popularity: 32% [?]
