SRM Re-install Required after vCenter 6 re-install

Quick heads up.

I had to re-install my vCenter 6 because the PSC it was attached to was not replicating to the rest of the domain. I will cover what I had to do in another post, but I uncovered an issue with SRM after the re-install.

I re-installed SRM (re-using the same database) and everything was ok until it tried to start the application. At that point I saw this in the logs:

016-04-28T02:31:57.638-07:00 [05240 panic ‘Default’ opID=43110d3c] –>
–> Panic: Assert Failed: “from->GetDatastoreMoId() == to->GetDatastoreMoId() (Dr::Storage::DataAccess::`anonymous-namespace’::CopyReplicatedDatastoreDbObj: The source datastore MoRef (MoRef=[datastore-730410:vim.Datastore:90cd9058-6f7b-49b5-9fdb-a9a55ef08ba2]) does not match the target datastore MoRef (MoRef=[datastore-730410:vim.Datastore:C9BF8D0B-90CF-4D06-A3BB-31678C733D67]))” @ d:/build/ob/bora-2700459/srm/src/storage/dataaccess/dbUtils.cpp:1548
–> Backtrace:
–>
–> [backtrace begin] product: VMware vCenter Site Recovery Manager, version: 6.0.0, build: build-2700459, tag: –
–> backtrace[00] vmacore.dll[0x001BC46A] –> backtrace[01] vmacore.dll[0x0005B92F] –> backtrace[02] vmacore.dll[0x0005CA5E] –> backtrace[03] vmacore.dll[0x001D4F45] –> backtrace[04] vmacore.dll[0x001D503D] –> backtrace[05] vmacore.dll[0x0004CBFC] –> backtrace[06] dr-storage.dll[0x0027914C] –> backtrace[07] dr-storage.dll[0x00257197] –> backtrace[08] dr-storage.dll[0x00285CF5] –> backtrace[09] dr-storage.dll[0x0027B6FF] –> backtrace[10] dr-storage.dll[0x002466AF] –> backtrace[11] dr-storage.dll[0x000C3F29] –> backtrace[12] dr-storage.dll[0x002AE2BF] –> backtrace[13] dr-storage.dll[0x002B2E22] –> backtrace[14] dr-storage.dll[0x00297219] –> backtrace[15] dr-storage.dll[0x002966AF] –> backtrace[16] dr-storage.dll[0x0029D72F] –> backtrace[17] common.dll[0x0003A47D] –> backtrace[18] vmacore.dll[0x001506FE] –> backtrace[19] vmacore.dll[0x00153F3F] –> backtrace[20] vmacore.dll[0x00155491] –> backtrace[21] vmacore.dll[0x001571C5] –> backtrace[22] vmacore.dll[0x00064EDB] –> backtrace[23] vmacore.dll[0x001526D0] –> backtrace[24] vmacore.dll[0x001D059B] –> backtrace[25] MSVCR90.dll[0x00002FDF] –> backtrace[26] MSVCR90.dll[0x00003080] –> backtrace[27] kernel32.dll[0x000159BD] –> backtrace[28] ntdll.dll[0x0002A2E1] –> [backtrace end] –>

Basically the re-install of vCenter generated a new UUID that does not match what is in the SRM database. I use array based replication, so it looks like the UUID of the vCenter is attached to the datsatores. GSS/CPD did not have a way for me to update that database. The only option was to re-install. I didn’t have a lot of customization so I went ahead and re-installed, but it would have sucked if I did have a lot of custom workflows (SRM’s API/powercli is still very lacking).
Also of note, the vCenter name changed when I re-installed, but I’m not sure if that caused a new UUID. During the vCenter upgrades I did a few re-installs of vCenter (where the name changed) and didn’t see a corresponding issue with SRM (this was prior to the SRM 6 upgrade). My guess is that once SRM is that either vCenter 6 re-install generates a new UUID (maybe from the PSC) or SRM 6 starts to store that information for the first time.