"Unable to perform query" error when attempting to perform actions in the Cloud Director HTML5 UI
search cancel

"Unable to perform query" error when attempting to perform actions in the Cloud Director HTML5 UI

book

Article ID: 320542

calendar_today

Updated On:

Products

VMware Cloud Director

Issue/Introduction

Symptoms:
  • Attempting to perform an action in the Cloud Director UI results in an error being displayed:
    Unable to perform query
  • API or browser requests show an incorrect FQDN in the URLs for the endpoints in the response body of requests.
  • Actions such as Editing or Creating an Edge Gateway show the error above when trying to set External Networks.


Environment

VMware Cloud Director for Service Provider 10.x
VMware Cloud Director 10.x
VMware Cloud Director for Service Provider 9.x

Cause

The Cloud Director UI relies on the URL links received in response to requests to build subsequent request URLs.
If these response URLs received by a browser do not contain a valid address with the expected FQDN the correct request URL may not be available.
The Cloud Director UI in a browser may not then be able to build a valid request to retrieve data from the Cloud Director Cell servers resulting in an error of the form:
Unable to perform query

Resolution

Ensure that the Public Addresses of the Cloud Director are correctly set in the Provider UI as outlined in the documentation here, Configure Public Addresses.

If Cloud Director's Public Address points to a load balancer, reverse proxy, or another network device used to manage traffic to and from Cloud Director ensure that this other device is not manipulating the body of responses.
For example a load balancer may have traffic rules that change the body of the content sent by Cloud Director to a connected browser. This could involve changing the FQDN within URLs in the XML or JSON response body and thus create invalid URLs that result in the error above.

To determine if the correct URLs are being returned by Cloud Director in the body of responses perform the following steps:

  1. Make a request to the /api/versions endpoint of Cloud Director's public address.
NOTE: This test should be done from the same location that any errors are seen.
This can be done simply by opening it in a browser, for example:

https://vcloud.example.com/api/versions

Alternatively the specific API call can be made manually using Curl for example:

curl -k https://vcloud.example.com/api/versions
 
  1. Examine the XML body of the response and ensure that the URLs within the LoginUrl sections match the Cloud Director public address to which you made the call, in this example vcloud.example.com. If there is a mismatch this would suggest another network device is interfering with the response or the public addresses are not correctly configured:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SupportedVersions xmlns="http://www.vmware.com/vcloud/versions" xmlns:ns2="http://www.vmware.com/vcloud/v1.5" xmlns:vmext="http://www.vmware.com/vcloud/extension/v1.5" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:common="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:ovfenv="http://schemas.dmtf.org/ovf/environment/1">
    <VersionInfo deprecated="true">
        <Version>27.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="true">
        <Version>28.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="true">
        <Version>29.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="true">
        <Version>30.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>31.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>32.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>33.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>34.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <SchemaRoot>https://vcloud.example.com/api/v1.5/schema/</SchemaRoot>
</SupportedVersions>
  1. Determine the HTTP/API endpoint of one of the Cloud Director Cell servers in this Cloud Director instance. For example this could be done by checking the global.properties file via SSH on one of the Cell servers:
grep 'vcloud.cell.ip.primary' /opt/vmware/vcloud-director/etc/global.properties
vcloud.cell.ip.primary = <IP>
  1. Test again the response given when requesting the /api/versions endpoint but this time using this Cloud Director Cell IP directly to bypass any load balancer or other network management device:
Again this can be done simply by opening it in a browser, for the example IP <IP> above we would use the following URL:

https://<IP>/api/versions

Alternatively the specific API call can be made manually using Curl for example:

curl -k https://<IP>/api/versions
  1. Despite using the IP of the Cell directly in the request we should continue to see the correct public address URLs within the LoginUrl sections in the XML response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SupportedVersions xmlns="http://www.vmware.com/vcloud/versions" xmlns:ns2="http://www.vmware.com/vcloud/v1.5" xmlns:vmext="http://www.vmware.com/vcloud/extension/v1.5" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:common="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:ovfenv="http://schemas.dmtf.org/ovf/environment/1">
    <VersionInfo deprecated="true">
        <Version>27.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="true">
        <Version>28.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="true">
        <Version>29.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="true">
        <Version>30.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>31.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>32.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>33.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <VersionInfo deprecated="false">
        <Version>34.0</Version>
        <LoginUrl>https://vcloud.example.com/api/sessions</LoginUrl>
    </VersionInfo>
    <SchemaRoot>https://vcloud.example.com/api/v1.5/schema/</SchemaRoot>
</SupportedVersions>
  1. If there is a mismatch between the FQDNs within the LoginUrl sections in the XML seen in steps 2. and 5. then either the public addresses are not configured correctly or a network management device, such as a load balancer, is changing the content of the responses.
  2. If the public addresses in Cloud Director have been set as per the documentation above and the UI shows the correct FQDN then check them also via the API. Use the direct IP of a Cloud Director Cell to avoid any issues, in this example we will continue to use <IP> retrieved in step 3. above:
    1. Login to the Cloud Director API as per the API documentation, VMware Cloud Director API Programming Guide, Logging In.
    2. Retrieve the general settings of Cloud Director via the API:
Request:
GET https://vcloud.example.com/api/admin/extension/settings/general
Request Headers:
Accept: application/*+xml;version=34.0
Authorization: Bearer <X-VMWARE-VCLOUD-ACCESS-TOKEN>
  1. Examine the configured public addresses and confirm that the following fields contain the correct public FQDN:
RestApiBaseHttpUri
RestApiBaseUri
TenantPortalExternalHttpAddress
TenantPortalExternalAddress

NOTE: Some older or upgraded versions of Cloud Director may also have the following fields:
SystemExternalAddress
SystemExternalHttpAddress
  1. To change the addresses if they are incorrect perform a PUT supplying the XML retrieved in step b. as the body but with the incorrect FQDN found in the fields from c. above altered to the correct value.
Request:
PUT https://vcloud.example.com/api/admin/extension/settings/general
Request Headers:
Accept: application/*+xml;version=34.0
Authorization: Bearer <X-VMWARE-VCLOUD-ACCESS-TOKEN>
Content-Type: application/*+xml
Body:
Altered XML with updated RestApiBaseHttpUri, RestApiBaseUri, TenantPortalExternalHttpAddress, TenantPortalExternalAddress, SystemExternalAddress, and/or SystemExternalHttpAddress values.
 
  1. If the issue continues to persist then any network management device between the browser and the Cloud Director Cells should be investigated to remove the feature manipulating the response body.


Powered by Wolken Software