vCloud Director – vCenter Single Sign-On Integration Troubleshooting

The access to vCloud Director provider context (system administrator accounts) can be federated with vCenter Single Sign-On. This means that when vCloud system administrator wants to log into the vCloud Director (http://vCloud-FQDN/cloud) he is redirected to vSphere Web Client where he needs to authenticate and then redirected back to vCloud Director.


Here follows collection of topics that might be useful when dealing when troubleshooting the federation:

1. When the SSO federation is enabled the end-user is always redirected to vSphere Web client. If you want to use local authentication use http://vCloud-FQDN/cloud/login.jsp and type local or LDAP account (if LDAP is configured).

2. If you enabled SSO federation and the vCenter SSO is no longer available, you cannot unregister its lookup service. To do this go to vCloud database and in dbo.config table clear the lookupservice.url value.

3. In case you are using self-signed untrusted certificate on the vSphere web client some browsers (Firefox) might not display the Add Security Exception button when being redirected. Therefore open first the vSphere web client page directly, create the security exception and then the redirection from vCloud website should work.

4. HTTP ERROR 500. Problem accessing /cloud/saml/HoKSSO/alias/vcd. Reason: Error determining metadata contracts
Metadata for issuer https://xxx:7444/STS wasn’t found

This error might appear after the vSphere web client SSO authentication when the user is redirected back to vCloud portal. To understand this error let’s first talk about what is going on in the background. When the SSO federation is enabled, vCloud Director establishes trust with vCenter SSO. The trust is needed so the identity provider (SSO) knows that the request for authentication is not malicious (phishing) and also the service provider (vCloud Director) needs to be sure the reply comes from the right identity provider.

The trust is established when the federation is configured with metadata exchange that contains keys and some information about the other party. The SSO metadata can be seen in vCloud Director database in the dbo.saml_id_provider_settings table. Now during the actual authentication process if for some reason the security token reply comes from different source than the one expected based on the identity provider metadata, you will get this error.

This issue might happen for example if the vCenter SSO hostname has been changed. In this particular case which I encountered it happened on vCenter Server Appliance 5.1. The SSO has been initiated before the hostname was set. So the identity provider response came with metadata containing the issuer’s IP address instead FQDN which the service provider (VCD) expected based on the SSO endpoint address. The issuer information did not get updated after the hostname change.

The VCSA 5.1 the issuer information is stored in SSO PostgreSQL DB. These are the steps to change it:

  1. Get the SSO DB instance name, user and password

cat /usr/lib/vmware-sso/webapps/lookupservice/WEB-INF/classes/


  1. Connect to the DB with the password retrieved from the previous step (db.pass=…)

/opt/vmware/vpostgres/1.0/bin/psql ssodb -U ssod

Retrieve the STS issuer:

ssodb=> select issuer from ims_sts_config;

If the issuer is really incorrect update it with following command:

ssodb=> update ims_sts_config SET issuer='https://FQDN:7444/STS'

Note: I need to credit William Lam for helping me where to find the SSO DB password.

Memory Overhead in vCloud Director

This little known fact came up already twice recently so I will write just a short post about it.

In the past when you created allocation pool Organization Virtual Datacenter (Org VDC) and allocated to it for example 20 GB RAM it actually did not allow you to deploy VMs with total memory sum of 20 GB due to virtualization memory overhead being charged against the allocation as well. This behavior forced service providers to add additional 5%-15% to the memory Org VDC allocation. This was also very confusing for the end users who were complaining why their VM cannot power on.

With the elastic allocation pool VDC changes which came with vCloud Director 5.1 it is no longer an issue. The reason is that in the non-elastic VDC it is vSphere (and Org VDC resource pool object with a limit set) who does the admission control – i.e. how many VMs can be deployed into it. In the elastic VDC it is actually vCloud Director who is responsible for the decision if a VM can be deployed into particular VDC.

Allocation Pool Elasticity

So to sum it up: if you use elastic allocation pool the tenant can use it up to the last MB. The virtualization VM memory overhead is charged to the provider who must take it into account when doing capacity management.

Datastore Cluster Issue in vCloud Director 5.5.1

Just found out there is a known issue with removing datastores in and out of datastore clusters. In vCloud Director 5.1 this was working fine. vCloud Director refers to storage via storage policies (formerly profiles) so you could on-the fly change the datastore cluster structure (as long as all datastore inside had the same storage policy).

However in vCloud Director 5.5.1 if you move a datastore in or out of a datastore cluster, vCloud Director will loose it. The fix is described in KB 2075366 and involves clean up of vCloud Director database inventory data.

VXLAN as an External vCloud Director Network

I was asked by a customer how to use a VXLAN network as an external network in vCloud Director. I thought there was already written blog article about it bud did not find any. So writing the answer here will benefit hopefully others as well.


First questions would be why would you do it? Aren’t vCloud Director external networks supposed to be the way to connect internal vCloud networks (usually VXLAN based) to the external world via VLAN based networks through a Edge Gateway device? Yes, but there are a few use cases for use of VXLAN network as an external network.

  • Usage of different virtual edge router other than vShield Edge that supports needed features (IPv6, dynamic routing protocols). In picture below you see virtual Fortigate router in place of vShield Edge. The router is deployed manually and its internal interface is connected to a VXLAN network (again created manually) which acts as external network that is directly connected to OrgVDC network. This helps saving VLANs which are usually scarce resource in service provider environment.
    Virtual Router
  • Service network spanning multiple pods crossing L3 boundaries. Each pod (cluster) has its own L2 networking so VLAN cannot span all clusters. However VXLAN can. So service network (for example syslog or monitoring network) can be used by any VM in any rack. See this article how to secure such network in multitenant environment.
    Service Network


Although you can easily manually create a VXLAN network directly in vShield Manager (or in vSphere Web Client if you use NSX) you will not see the VXLAN portgroup in vCloud Director GUI.

Service Network

External Networks 1

The fix is simple. vCloud Director is filtering out all portgroups that start with ‘vxw’ string. Rename the portgroup in vCenter Server (remove the string) and you will be able to select the portgroup as an External Network.

External Networks 2

How To Download vCloud VMRC Plugin

I had a question if there is a way to download vCloud Director VMware Remote Console plug-in without the need to actually log in into vCloud Director. For example in order to prepare desktop images for your vCloud users.

Yes, it is possible and here are the links for vCloud Director 5.5:


where vcd-url is the vCloud Director endpoint address. For example in case of vCHS the link looks like: (replace XXX with your particular cloud instance name).