Error: "You have no privileges to view this object, or it is deleted" when accessing Storage group via 3rd party VASA plugin on vCenter
search cancel

Error: "You have no privileges to view this object, or it is deleted" when accessing Storage group via 3rd party VASA plugin on vCenter

book

Article ID: 427529

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

  • After splitting or removing vCenter Server from ELM (Enhanced Linked Mode) and converting to standalone, after logging into vSphere Client as Administrator and visiting Menu (Top-Let corner) > VASA Plugin Name (At the bottom of the list) > Storage groups and clicking on a Storage Group encounters "You have no privileges to view this object, or it is deleted" error as shown below:

  • On vSphere > Solutions > Client Plugins, the plugin is verified to be online and healthy :

  • Reviewing the /var/log/vmware/vsphere-ui/vsphere_client_virgo.log on vCenter server reveals that the 3rd party VASA plugin extension is attempting to communicate with the decommissioned partner vCenter "decommissioned_vcenter_fqdn" and encountering "No route to Host"

[YYYY-MM-DDThh:mm:ss] [INFO ] data-service-pool-781 7002##11 10##34 20##48 com.<vendorName>.hi.service.html5.vmware.VCenterService [<VendorName>] - Timer load<VendorName>Extensions: 1#.## μs - building group map for vcenter VCenterInfo [name=null, vcenterUuid=0a####30-e##0-4##0-a##d-49########b1, serviceUrl=https://<decommissioned_vcenter_fqdn>:443/sdk, session=null, thumbprint=##:##:##:##, version=null]
[YYYY-MM-DDThh:mm:ss] [INFO ] data-service-pool-781 7002##11 10##34 20##48 com.<vendorName>.hi.service.html5.vmware.VCenterService [<vendorName>] - Timer load<vendorName>Extensions: 1##.# μs - Loading extension for vcenter VCenterInfo [name=null, vcenterUuid=0a####30-e##0-4##0-a##d-49########b1, serviceUrl=https://<decommissioned_vcenter_fqdn>:443/sdk, session=null, thumbprint=##:##:##:##, version=null]
[YYYY-MM-DDThh:mm:ss] [WARN ] data-service-pool-781 7002##11 10##34 20##48 com.<vendorName>.hi.service.html5.vmware.VCenterService [<vendorName>] - Timer get<vendorName>WebExtension: start
[YYYY-MM-DDThh:mm:ss] [WARN ] data-service-pool-781 7002##11 10##34 20##48 com.<vendorName>.hi.service.html5.vmware.VCenterService [<vendorName>] - Timer get<vendorName>WebExtension: end - 3.0## s - extension loaded
[YYYY-MM-DDThh:mm:ss] [ERROR] -nio-127.0.0.1-5090-exec-663 7002##11 10##34 20##48 com.vmware.vise.mvc.exception.GlobalExceptionHandler Exception handled while processing request for /ui/data/properties/urn:ns:<vendorName>:<Group>:8#####7?properties=name,primaryIconId: com.google.common.util.concurrent.UncheckedExecutionException: com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.NoRouteToHostException: No route to host (Host unreachable)
        at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
        at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
        at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
        at com.<vendorName>.hi.service.html5.vmware.VCenterService.getRegistered<vendorName>GroupsFromCache(VCenterService.java:196)
        at com.<vendorName>.hi.service.html5.dpa<vendorName>GroupDataAdapter.processObjectIdentityConstraint(<vendorName>GroupDataAdapter.java:339)

Cause

Sometimes after a vCenter Server has been converted from ELM to standalone, it might retain stale references to its previous ELM partner vCenter(s), thus causing this issue.

Resolution

To resolve the issue, you must remove the stale references to the decommissioned ELM partner vCenter(s) from the current vCenter Server's Single Sign-On (SSO) configuration by following either of the below methods

Note: Ensure to take a valid, offline snapshot of the vCenter Server Appliance before proceeding.

  1. SSH to the vCenter as root and fetch its node id using the below command:

    cat /etc/vmware/install-defaults/vmdir.ldu-guid

  2. Create a text file with a list of the services registered within the vCenter by runing the below command:

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

    The above command will list out multiple services, many of them having duplicate registrations with different Service ID and Node ID  i.e one for current vCenter and the other(s) for decommissioned ELM partner vCenters

    Below is an example of one such service:

    Name: AboutInfo.vpx.name
    Description: AboutInfo.vpx.name
    Service Product: com.vmware.cis
    Service Type: vcenterserver
    Service ID: <service_id_1>
    Site ID: default-first-site
    Node ID: <node_id_vC_standalone>
    Owner ID: vpxd-#######-####-####-####-######@vsphere.local
    Version: 8.0
    Endpoints:
    Type: com.vmware.vim.extension
    Protocol: vmomi
    URL: https://<vC_standalone_fqdn>:443/sdkTunnel

    Name: AboutInfo.vpx.name
    Description: AboutInfo.vpx.name
    Service Product: com.vmware.cis
    Service Type: vcenterserver
    Service ID: <service_id_2>
    Site ID: default-first-site
    Node ID: <node_id_decommissioned_vC>
    Owner ID: vpxd-#######-####-####-####-######@vsphere.local
    Version: 8.0
    Endpoints:
    Type: com.vmware.vim.extension
    Protocol: vmomi
    URL: https://<decommissioned_vC_fqdn>:443/sdkTunnel

  3. Use the any of the below methods to remove the stale traces pertaining to <node_id_decommissioned_vC>

  4. Restart the vCenter Server services by running the following command: service-control --stop --all && service-control --start --all

Powered by Wolken Software