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 begin] product: VMware vCenter Site Recovery Manager, version: 6.0.0, build: build-2700459, tag: –
–> backtrace vmacore.dll[0x001BC46A] –> backtrace vmacore.dll[0x0005B92F] –> backtrace vmacore.dll[0x0005CA5E] –> backtrace vmacore.dll[0x001D4F45] –> backtrace vmacore.dll[0x001D503D] –> backtrace vmacore.dll[0x0004CBFC] –> backtrace dr-storage.dll[0x0027914C] –> backtrace dr-storage.dll[0x00257197] –> backtrace dr-storage.dll[0x00285CF5] –> backtrace dr-storage.dll[0x0027B6FF] –> backtrace dr-storage.dll[0x002466AF] –> backtrace dr-storage.dll[0x000C3F29] –> backtrace dr-storage.dll[0x002AE2BF] –> backtrace dr-storage.dll[0x002B2E22] –> backtrace dr-storage.dll[0x00297219] –> backtrace dr-storage.dll[0x002966AF] –> backtrace dr-storage.dll[0x0029D72F] –> backtrace common.dll[0x0003A47D] –> backtrace vmacore.dll[0x001506FE] –> backtrace vmacore.dll[0x00153F3F] –> backtrace vmacore.dll[0x00155491] –> backtrace vmacore.dll[0x001571C5] –> backtrace vmacore.dll[0x00064EDB] –> backtrace vmacore.dll[0x001526D0] –> backtrace vmacore.dll[0x001D059B] –> backtrace MSVCR90.dll[0x00002FDF] –> backtrace MSVCR90.dll[0x00003080] –> backtrace kernel32.dll[0x000159BD] –> backtrace 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.