SRM recovery site removed uncleanly. SRM from protected site uninstalled. Hosts & VM's have errors.

[tman84]

Hi,

We performed some tested with SRM, part of which was to isolated the recovery site and perform a recovery of VM's.

Because this was just a test, when we were done we decommissioned the recovery site test environment and uninstalled SRM from the protected site.

Because the recovery site was removed uncleanly we continue to get errors on the Hosts and VM's that they are unable to communicate with the recovery site.

I thought that this would be taken care of when SRM was uninstalled, but this doesn't seem to be the case.

For the VM's they are displaying the error:

No connection to VR Server: Not responding. warning

On the Host that the VM sits there are the follow errors.

On the hostd.log:

[5B803B90 error 'Hbrsvc'] ReplicationGroup get-server-state request failed, will retry (groupID=GID-dfe64ab6-4922-49c9-8920-de47c5758d16): Not found

On the vmkernel.log:

WARNING: Hbr: 534: Connection failed to 192.168.30.204 (groupID=GID-14dcc90d-3e2e-4a86-8aa7-74dc9abb0569): Timeout

WARNING: Hbr: 4322: Failed to establish connection to [192.168.30.204]:44046(groupID=GID-14dcc90d-3e2e-4a86-8aa7-74dc9abb0569): Timeout

Hbr: 1064: Failed to find NetWorker for groupID=GID-dfe64ab6-4922-49c9-8920-de47c5758d16

WARNING: Hbr: 6043: Failed to find NetWorker (groupID=GID-dfe64ab6-4922-49c9-8920-de47c5758d16) (Command=GET_SERVER_STATE)

How do I resolve these errors from occurring? Do I need to remove the GID state above?

Any assistance would be appreciated.

Thanks,

Trent

[mvalkanov · Accepted solution]

Hi Trent,

Which SRM/VR version is this? Is VRMS configured with externel DB or using embedded DB?

Now that the recovery site has been decommissioned, the VRMS at the source site still thinks that the VMs are configured for replication.

To clean up the source VMs from the replication configuration, you need to boot up VRMS with empty DB - it will remove the replication configuration from the source VMs, as these configuration will no longer be present in the VRMS DB. To achieve this:

Option A) Power off and delete the old VR appliance at the source site and deploy and configure a new one.

Option B) If using VR 5.1 or 5.5 with embedded DB, it can be easier to simply click the "Reset embedded DB" button in the VAMI UI.

Option C) If VRMS has been configured with external DB, an alternative to re-deploying the appliance would be to stop VRMS service (/etc/init.d/hms stop), drop the old VRMS database, create a new one and configure VRMS with the new DB from the VAMI UI.

Once the replication configurations have been removed, you can click on "Unregister from vCenter Server" button in VRMS VAMI UI to unregister the extension from VC and power off and delete the appliance. There won't be any leftovers.

At the recovery site - if the datastores have not been reformatted, but only VR appliances removed, you might need to clean up the replication target folders.

Regards,

Martin

[tman84]

Great stuff! Thanks for the assistance.

I was using 5.1 with an embedded DB

Option A was the only thing I could really do as I had already deleted the old VR appliance.

To be sure, I did also go with Option B, although this is just doubling up.

I was having an issue with one of my VM's. But I was able to manually disable replication from the host.

I ran vim-cmd hbrsvc/vmreplica.abort vmid followed by vim-cmd hbrsvc/vmreplica.disable vmid

This combination, seems to have resolved the errors from occurring for both VM's and hosts.

Thanks again,

Trent