In Zerto 5.0, a new feature was implemented to track MorefID changes that occur when a host is removed/re-added to inventory and similar events in vCenter. The feature works by referencing a database table called “IdentifierMapperStorageObject” which tracks the original MorefIDs and their new values.
During upgrade from 4.5.x to 5.0.x, this table is freshly created using pass-through/equivalent values for all MorefIDs.
Zerto development has determined that in rare cases, a race condition can arise during the creation of this table which results in identical lines being entered multiple times. Having multiple lines referencing the same MorefIDs causes an exception when the table is queried.
This also causes a failure to collect the vCenter reflection, which is the mechanism through which the ZVM tracks changes in vCenter.
If this issue is encountered, ZVM upgrade will appear to succeed, but VRA upgrades will fail to complete, and VRAs will be left in a non-operational state.
To worikaround the issue, the ZVM tweak “t_enablePlatformIdentifierMapping =”false”” should be applied. This tweak disables the new feature for MorefID lookup, and
therefore allows reflection collection to succeed.
However, the duplicate lines in the table may still exist, and when these lines are referenced during the VRA upgrade attempts, the process will fail.
Zerto support must then be engaged to manually remove all duplicate lines from the “IdentifierMapperStorageObject” table in the ZVM.sdf database. VRA upgrade should then be successful.
If upgrading to 5.0u3, the race condition cannot occur because the “t_enablePlatformIdentifierMapping =”false”” is set by default in this version. No manual editing of the tweaks file is necessary if upgrading to 5.0u3.
The race condition itself is slated to be completely fixed in 5.0u4. Customers previously impacted by this issue can safely remove the “t_enablePlatformIdentifierMapping =”false”” tweak once they have upgraded to 5.0u3 or 5.0u4 or higher.