SRM Plugin fails to deploy with error "URL is unreachable. No route to host"
search cancel

SRM Plugin fails to deploy with error "URL is unreachable. No route to host"

book

Article ID: 426541

calendar_today

Updated On:

Products

VMware Live Recovery

Issue/Introduction

Symptoms:

  • When attempting to reinstall or reconfigure Site Recovery Manager and vSphere Replication appliances, the plugin fails to deploy.

  • The reconfiguration task initiated on the SRM and VR appliances completes successfully

  • Once the appliance is configured successfully via the VAMI, returning to the vSphere Client displays the below error. The status of the plugin can also be verified under vCenter Server Menu > Administration > Client plugins

    Error downloading plug-in. URL is unreachable. No route to host (Host unreachable)

  • The URL cited in the error points to the IP/FQDN of an old or powered-off vSphere Replication or SRM appliance.

Environment

VMware Live Site Recovery 9.x

Cause

This issue is caused by stale service registrations within the vCenter server lookup service. When the new appliance attempts to deploy the plugin, vCenter server still holds references to the legacy appliance service IDs. Consequently, the vSphere Client attempts to pull plugin data from the decommissioned appliance instead of the new one resulting in this error.

Cause Validation:

  • Run the following command on the problematic vCenter server to export all service registrations

    /usr/lib/vmware-lookupsvc/tools/lstool.py list --url http://localhost:7090/lookupservice/sdk > /tmp/psc_services.txt

  • Search the output for SRM and VR plugin entries (specifically the h5-dr service type)

    less  /tmp/psc_services.txt  | grep -iC4 h5-dr

    Sample output:

        Name: VMware Site Recovery
        Description: Site Recovery Web Client Plugin
        Service Product: com.vmware
        Service Type: vrUi
        Service ID: h5-dr-7c######-####-####-####-############
        Site ID: default-first-site
        Owner ID: h5-dr-sa-7c######-####-####-####-############@[email protected]
        Version: 8.5.0.18810983
        Endpoints:
                Type: com.vmware.dr.ui
                Protocol: http
--
        Name: VMware Site Recovery
        Description: Site Recovery Web Client Plugin
        Service Product: com.vmware
        Service Type: vrUi
        Service ID: h5-dr-d0######-####-####-####-############
        Site ID: default-first-site
        Owner ID: h5-dr-sa-d0######-####-####-####-############@vsphere.local
        Version: 8.8.0.23263429
        Endpoints:
                Type: com.vmware.dr.ui
                Protocol: http

--
                Name: VMware Site Recovery
        Description: Site Recovery Web Client Plugin
        Service Product: com.vmware
        Service Type: vrUi
        Service ID: h5-dr-ab######-####-####-####-############
        Site ID: default-first-site
        Owner ID: h5-dr-ab######-####-####-####-############@vsphere.local
        Version: 9.0.1.24035640
        Endpoints:
                Type: com.vmware.dr.ui
                Protocol: http

In the above output, we see entries with older versions indicating stale entries

Resolution

Follow these steps to perform a manual cleanup of the stale extensions and service registrations.

Pre-requisites:

  • Take a offline snapshot of the vCenter Server before proceeding.
  • Ensure the old SRM/VR appliances are powered off.

1. Use the lstool.py utility to remove the stale service IDs identified during the validation phase from the vcenter server

/usr/lib/vmware-lookupsvc/tools/lstool.py unregister --url http://localhost:7090/lookupservice/sdk --user "[email protected]" --password 'Password' --id 'Service ID'

2. Restart all vCenter server services to clear the cache and initialize the clean state

service-control --stop --all && service-control --start --all

3. Reconfigure the SRM and VR appliances from VAMI and the plugin should now deploy successfully.