Hi Martin,
Thanks for the help. I'll look into opening a SR with VMware. Right now, it appears I have successfully found an work around.
After the "optimistic" failure, I couldn't get that particular VM to be VR configured again, because I was receiving another kind of error: [Call "HmsGroup.CurrentSpec" for object "GID-aef7837-8dd7-8dd7-4aa2-bc7d-8d67cba47363" on Server "vrms-server.local.com" failed. An unknown error has occurred.]
Looking around the Internet, I found several people that has passed this GID error. Many advices on the foruns tell to remove the VM from inventory and then re-add it. However, in order to do this, we need to shutdown the VM, but I wasn’t keen to do that.
I think the remove/re-add from inventory action works because when we do that, vCenter generates a different Managed Object ID (MoID) for the VM, so if the VM MoID was “vm-3882”, when it is re-added, it will be something different, so later the GID will also be something different. More information on Managed Object Reference (MoRef) in vCenter Server, can be found here http://kb.vmware.com/kb/1017126.
The GID number I believe is a VR ID for the VM, so when the first error hit (in my case, the “optimistic” failure), somehow that GID get “jinxed” in the VMRS DB and SRM will never even try to configure VR on it again. The trick I found was to, instead of creating a new MoID by readding the VM to inventory, I just deleted the DB rows where the problematic GID were. I found such rows in two tables of the VRMS database that match the GUID in the error message. The tables are:
So, I used T-SQL scripts to delete the row where the relationshinp between the VM MoID and the GID are recorded, [GrpSpecVM]; after that, I deleted the row where the relationship between the GID and the ConfigurationState are recorded, [PrimaryGroupEntity]. With these actions I manage to be able to right click the VM and start the VR again without receiveing the GID error and with the VM powered up all the time. I'm aware that this row deletion is not supported by VMware, and I haven’t received this information from them, and I have no idea if this is going to cause any trouble in the future – but it sure fixed the GID error.
Now back to my original problem ("optimistic" failure).
I also found a number of tips and hints about that, I tried all of them, and nothing was working. There was however, one of the tips, available at http://vblitz.joelprophoto.com/blitz-setup-vsphere-replication-srm-5-0/ that I haven't tried yet. It says:
I didn't pay attention to that tip, because I didn't see much sense in IMMEDIATELY doing the same thing without changing anything and expect a different result, but in this case, it actually worked! I had to repeat 3 times the same VR configuration I was doing in the same VM, and I noticed each time something was not 100% configured like the previous attempt, so I guess after the 3rd attempt it actually "sticks" 100% of the configs in the VRMS database and the initial sync finally started.
Anyway, just wanted to post here some information about the new workaround I found for the GID error, and also thanks the http://vblitz.joelprophoto.com post for the tip I initially was reluctant to follow and that in the end was what actually worked...
Regards,
Moracy