SRM Re-install Required after vCenter 6 re-install

By | May 9, 2016

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.


One thought on “SRM Re-install Required after vCenter 6 re-install

  1. Jonathan Wingfield

    I’ve had the same issue. I did not rename the vCenter server, but the UUID is still changed. VMware made it very quick and simple to rebuild the vCenter server, but the SRM team is way behind the curve. The SRM support is deplorable as well. I opened my ticket with VMware in early December, and by mid December they promised a fix within the next few days. Over a month later they have yet to deliver on that fix. I have a PoC with Zerto going right now and that will likely be our solution going forward.


Leave a Reply

Your email address will not be published. Required fields are marked *