The cause of this issue is network connectivity issues, the secondary VRM server intermittently losing connection with or being unable to communicate with the primary VRM server.
If a virtual machine Remove Replication operation is initiated on an affected VRM server, the operation completes on the secondary VRM server. However, it may not complete on the primary VRM if the network connectivity issue exists between the two VRM servers. Due to this synchronizing issue, it is likely that stale replication group records related to this virtual machine will remain on the primary VRM server database in the GID record, which looks similar to:
GID-67fc61da-2964-4d34-b7ff-b1d22938461b
The virtual machine replication state information shown in the VM view of the VR user interface is drawn from the information on the secondary VRM server. As the virtual machine replication information has been removed from the secondary VRM server, the virtual machine will not show as replicated in the VR GUI.
Attempting to configure replication for this virtual machine reveals errors reported by the primary VRM server. This is due to the presence of a stale replication record for that virtual machine, which is still in the primary VRM server's database. The primary VRM server queries the secondary VRM server for the same (stale) GID which cannot be found. Therefore, the primary VRM reports the
ManagedObjectNotFound error in the logs.