If you see this message during an SRM 5.8 upgrade, chances are you are doing what is a moderately rare type of an SRM install that has caused you some problems.
The given scenario that will lead to this situation:
You had a previous SRM install
You uninstalled SRM but left the old SRM database in place
You have installed a new vCenter and inventory service (or simply wiped and refreshed the inventory service database itself)
You are installing a new SRM instance
You chose to overwrite the SRM database as part of the new install
This was the scenario that brought me to run into the error “failed to clear inventory service registration” at the end of the SRM install. Retrying does nothing, and the only option is to cancel the install and roll back.
So why is this?
SRM tries to handle inventory service registration intelligently; in this case since it has found an existing database, the assumption is that you have re-installed SRM, but it knows nothing about the vCenter/IS components. SRM stores its UUID in its database, and then registers to inventory services with that UUID. If you were to reinstall SRM, the old UUID registered to IS would no longer be valid, so during our current situation it tries to remove the old registered UUID in order to use the new one with IS, the one it is putting into its new database.
In this scenario, what has happened is that when overwriting the SRM database during the install, SRM has tried to clean up the old SRM registration to Inventory Services by removing the UUID found in the old database. It does this to avoid conflicting SRM registrations in IS (e.g. if you were simply re-installing SRM alone.)
Since, however, you have a new vCenter and/or a new inventory service, that old UUID is no longer present, and the SRM install fails as it cannot find and unregister the UUID from IS that it finds in the old SRM database.
The solution can be one of two:
Retain the old SRM database instead of overwriting it. This may lead to some cleanup activities you’ll need to do if you purposefully needed to get rid of the old database information (which presumably is why you were overwriting it in the first place!).
Wipe out the SRM database before doing your install and start with a clean slate, instead of overwriting it. This is probably the easiest, and given that you were going to overwrite it anyway just takes a few moments up front.
This is likely a rare sort of scenario where you’re starting from scratch with everything but the SRM database. Most likely you’ll come across this in a lab/testbed environment where you run through installs and upgrades on a regular basis.
So not a big deal, but hopefully this helps save someone the time that it took me to find it!
