Load Balancing vCloud Director with NSX-T

I just have had a chance for the first time to set up vCloud Director installation that was fronted by NSX-T based load balancer (version 2.4.1). In the past I have blogged how to load balance vCloud Director cells with NSX-V:

Load Balancing vCloud Director Cells with NSX Edge Gateway

vCloud OpenAPI – Large Payload Issue with Load Balancer

NSX-T differs quite a lot from NSX-V therefore the need for this article. The load balancer instance is deployed into the NSX-T Edge Cluster which is a set of virtual or physical NSX-T Edge Nodes. There are also strict sizing guidelines related to the size and number of LB and size of Edge Nodes – see the official docs.


Import your VCD public cert in the NSX Manager UI: System > Certificates > Import Certificate. You will need to provide name, full certificate chain, private key and set is as Service Certificate. If it is signed by Enterprise CA you will also before that import the CA cert.


Create new monitor in Networking > Load Balancing > Monitors > Add Active Monitor HTTPs

  • protocol HTTPs
  • monitoring port 443
  • default timers
  • HTTP Request Configuration: GET /cloud/server_status, HTTP Request Version: 1
  • HTTP Response Configuration: HTTP response body: Service is up.
  • SSL Configuration: Enabled, Client Certificate: None


Application Profile

Networking > Load Balancing > Profiles > Select Profile Type: Application > Add Application Profile > HTTP

Here in the UI we can set only Request Header Size and Request Body Size. Set both to 65535 maximum (65535 for header size and at least 52428800 for body size as ISO/OVA uploads use 50 MB chunks). We will later use API to also configure Response Header Size.

Persistence and SSL Profiles

I will reuse existing default-source-ip-lb-persistence-profile and default-balanced-client-ssl-profile.

Server Pools

Networking > Load Balancing > Server Pools > Add Server Pool

  • Algorithm: Least Connection
  • Active Monitor: picked the one created before
  • Select members: Enter individual members (do not enter port as we will reuse the pool for multiple ports)


Virtual Servers

We will add two virtual servers. One for UI/API and another for VM Remote Console connections. For both I have picked the same IP address from the cell logical segment. Ports will be different (443 vs 8443).

vCloud UI

  • Add virtual server: L7 HTTP
  • Ports: 443
  • Ignore Load Balancer placement for now
  • Server Pool: the one we created before
  • Application Profile: the one we created before
  • Persistence: default-source-ip-lb-persistence-profile
  • SSL Configuration: Client SSL: Enabled, Default Certificate: the one we imported before, Client SSL Profile: default-balanced-client-ssl-profile
    Server SSL: Enabled, Client Certificate: None, Server SSL Profile: default-balanced-client-ssl-profile

vCloud Console

  • Add virtual server: L4 TCP
  • Ports: 8443
  • Ignore Load Balancer placement for now
  • Server Pool: the one we created before
  • Application Profile: default-tcp-lb-app-profile
  • Persistence: disabled

Load Balancer

Now we can create load balancer instance and associate the virtual servers with it. Create the LB instance on the Tier 1 Gateway which routes to your VCD cell network. Make sure the Tier 1 Gateway runs on an Edge node with the proper size (see the doc link before).

Networking > Load Balancing > Load Balancers > Add Load Balancer

  • Size: small
  • Tier 1 Gateway
  • Add Virtual Servers: add the 2 virtual servers created in the previous step

Now we have the load balancer up and running you should get all green in the status column. We are not done yet though.

Firstly we need to increase the response header size as vCloud Director Open API sends huge headers with links. Without this, you would get H5 UI errors (Nginx 502 Bad Gateway) and some API calls would fail.  This can be currently done only with NSX Policy API. Fire up Postman or Curl and do GET and then PUT on the following URI:


in the payload change the response_header_size to at least 10240 50000 bytes.

And finally we will need to set up NAT so our load balanced virtual servers are available both from the outside world (on Tier-0 Gateway) as well from the internal networks. This is quite network topology specific, but do not forget the cells itself must properly connect to the public (load balanced) URL configured in vCloud Director public addresses.


vCloud Director 9.7 Appliance Tips

About half a year ago I published blog post with similar title related to vCloud Director 9.5 appliance. The changes between appliance version 9.5 and 9.7 are so significant therefore I am dedicated a whole new article to the new appliance.


The main difference compared to 9.5 version is that vCloud Director 9.7 now comes with embedded PostgreSQL database option that supports replication, with manually triggered semi-automated fail over. The external database is no longer supported with the appliance. Service providers can still use Linux installable version of vCloud Director with external PostgreSQL or Microsoft SQL databases.

The appliance is provided in single OVA file that contains 5 different configurations (flavors). Primary node (small and large), Standby node (small and large) and vCloud Director cell application node.

All node configurations include the vCloud Director cell application services, the primary and standby also includes the database and the replication manager binaries. It is possible to deploy non-DB HA architecture with just the primary and cell nodes, however for production the DB HA is recommended and requires minimum of 3 nodes. One primary and two standbys. The reason for the need of two standby is, that at the moment the replication is configured, PostgreSQL database will not process any write requests as it is not able to synchronously replicated them to at least one standby node. This has some implications also how to remove nodes from clusters which I will get to.

I should also mention that primary and standby nodes once deployed are from appliance perspective equivalent, so standby node can become primary and vice versa. There is always only one primary DB node in the cluster.

NFS transfer share is required and is crucial for sharing information among the nodes about the cluster topology. In the appliance-nodes folder on the transfer share you will find data from each node (name, IP addresses, ssh keys) that are used to automate operations across the cluster.

Contrary to other HA database solution, there is no network load balancing or single floating IP used here, instead all vCloud Director cells are for database access always pointed to the eth1 IP address of the (current) primary node. During the failover the cells are dynamically repointed to the IP of the new node that takes the role of primary.

Speaking about networking interfaces, the appliance has two – eth0 and eth1. Both must be used, and  must have different subnets. The first one (eth0) is primarily used for the vCloud Director services (http – ports 80, 443, console proxy – port 8443, jmx – ports 61611, 61616), the second one (eth1) primary role is for database communication (port 5432). You can use both interfaces for other purposes (ssh, management, ntp, monitoring, communication with vSphere / NSX, ..). Make sure you follow the correct order during their configuration. It is so easy to mix up the subnets or port groups.

Appliance Deployment

Before starting deploying the appliance(s) make sure NFS transfer share is prepared and empty. Yes, it must be empty. When the primary node is deployed, responses.properties and other files are stored on the share and used to bootstrap other appliances in the server group and the database cluster.

The process always starts with the primary node (small or large). I would recommend large for production and small for everything else. Quite a lot of data must be provided in the form of OVF properties (transfer share path, networking, appliance and DB passwords, vCloud Director initial configuration data). As it is easy to make mistake I recommend snapshoting the VM before the first power-on so you can always revert back and fix whatever was wrong (the inputs can be changed in vCenter Flex UI, VM Edit Settings, vApp Options).

To see if the deployments succeeded or why it failed, examine the following log files on the appliance:

firstboot: /opt/vmware/var/log/firstboot
vcd setup:  /opt/vmware/var/log/vcd/setupvcd.log

config data can be checked in: /opt/vmware/etc/vami/ovfEnv.xml

Successful deployment of the primary node results in a single node vCloud Director instance with non-replicated DB running on the same node and with responses.properties file saved to the transfer share ready for other nodes. The file contains database connection information, certificate keystore information and secret to decrypt encrypted passwords. Needless to say, pretty sensitive information to make sure the access to NFS is restricted.

Note about certificates: the appliance generates its own self-signed certificates for the vCloud Director UI/API endpoints (http) and consoleproxy access and stores them to user certificates.ks keystore in /opt/vmware/vcloud-director which is protected with the same password as the initial appliance root password. This is important as the encrypted keystore password in the responses.properties file will be used for configuration of all other appliances and thus you must deploy them with the same appliance root password. If not, you might end up with half working node, where database will be working but the vcd service will not due to failed access to the certificate.ks keystore.

To deploy additional appliance nodes you use standby or pure VCD cell node configs. For HA DB two standbys (at least). As these nodes all run VCD service, deploying additional pure VCD cell nodes is needed only for large environments. Size of the primary and standbys should always be the same.

Database Cluster Operations

Update 2019/06/14: The official documentation has been updated to include this information.

The database appliances currently provides very simple UI on port 5480 showing the cluster state with the only operation to promote standby node and that only if the primary is failed (you cannot in the UI promote standby while primary is running).

Here is a cheat sheet of other database related operations you might need to do through CLI:

  • Start, stop and reload configuration of database on a particular node:
    systemctl start vpostgres.service
    systemctl stop vpostgres.service
    systemctl reload vpostgres.service
  • Show cluster status as seen by particular node:
    sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
  • Planned DB failover (for example for a node maintenance). On the standby cell run:
    sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr standby switchover -f /opt/vmware/vpostgres/current/etc/repmgr.conf –siblings-follow

Location of important database related files:
psql (DB CLI client): /opt/vmware/vpostgres/current/bin/psql
configuration, logs and data files: /var/vmware/vpostgres/current/pgdata

How to Rejoin Failed Database Node to the Cluster

The only supported way is to deploy a new node. You should deploy it as standby node and as mentioned in the deployment chapter it will automatically bootstrap and replicate the database content. That can take some time depending on the databse size. You will need to clean up the old failed VCD cell in vCloud Director Admin UI – Cloud Cells section.

There is an unsupported way to rejoin failed node without redeploy, but use at your own risk – all commands are triggered on the failed node:

Stop the DB service:
systemctl stop vpostgres.service

Delete stale DB data:
rm -rf /var/vmware/vpostgres/current/pgdata

Clone DB from the primary (use its eth1 IP):
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby clone

Start the DB service:
systemctl start vpostgres.service

Add the node to repmgr cluster:
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby register –force

How to Remove Failed Standby Node from the Cluster

On the primary node find the failed node ID via the repmgr cluster status command:
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show

Now unregister failed node by providing its ID (e.g. 13416):
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister –node-id=13416

Clean up failed VCD cell in Cloud Cells VCD Admin UI.

How to Revert from DB Cluster to Single DB Node Deployment

As mentioned in the introduction, if you shutdown both (all) standby nodes, your primary database will stop serving write I/O request. So how to get out of this pickle?

First, unregister both (deleted) standbys via the previous mentioned commands:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister –node-id=<id1>
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister –node-id=<id2>

Delete appliance-nodes subfolders on the transfer share corresponding to these nodes. Use grep -R standby /opt/vmware/vcloud-director/data/transfer/appliance-nodes to find out which folders should be deleted.

For example:
rm -Rf /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node-38037bcd-1545-49fc-86f2-d0187b4e9768

And finally edit postgresql.conf and change synchronous_standby_names line to synchronous_standby_names = ”. This disables the wait for the transaction commit to at least one standby.

vi /var/vmware/vpostgres/current/pgdata/postgresql.conf

Reload DB config: systemctl reload vpostgres.service.  The database should start serving write I/O requests.

Upgrade and Migration to Appliance

Moving both from Linux cells or 9.5 appliance to 9.7 appliance with embedded DB requires a migration. Unfortunately, it is not possible to just upgrade 9.5 appliance to 9.7 due to the embedded database design.

The way to get to 9.7 appliance is you will first upgrade the existing environment to 9.7, then deploy a brand new 9.7 appliance based environment and transplant the old database content to it.

It is a not a simple process. I recommend testing it up front on a production clone so you are not surprised during the actual migration maintenance window. The procedure is documented in official docs, I will provide only high level process and my notes.

  • Upgrade existing setup to 9.7(.0.x) version. Shut down VCD service and backup the database, global.properties, responses.properties and certificate files. Shut down the nodes if we are going to reuse their IPs.
  • Prepare clean NFS share and deploy single node appliance based VCD instance. I prefer to do the migration on single node instance and then expand it to multi node HA when the transplant is done.
  • Shut down the vcd service on the appliance, delete its vcloud database so we can start with the transplant.
  • We will restore the database (if the source is MS SQL we will use cell-management-tool migration) and overwrite global.properties and responses.properties files. Do not overwrite the user certificate.ks file.
  • Now we will run  the configure script to finalize the transplant. At this point on appliance I hit a bug that was related to SSL DB communication. In case your global.properties file contains vcloud.ssl.truststore.password line, comment it out and run the configure script with SSL disabled. This is my example:
    /opt/vmware/vcloud-director/bin/configure –unattended-installation –database-type postgres –database-user vcloud \
    –database-password “VMware1!” –database-host –database-port 5432 \
    –database-name vcloud –database-ssl false –uuid –keystore /opt/vmware/vcloud-director/certificates.ks \
    –keystore-password “VMware1!” –primary-ip \
    –console-proxy-ip –console-proxy-port-https 8443
  • Update 2019/05/24: The correct way to resolve the bug is to also copy truststore file from the source (if the file does not exist, which can happen if the source was freshly upgraded to or later start the vmware-vcd service at least once). The official docs will be updated shortly. The configure script can be then run with ssl set to true:
    /opt/vmware/vcloud-director/bin/configure –unattended-installation –database-type postgres –database-user vcloud \
    –database-password “VMware1!” –database-host –database-port 5432 \
    –database-name vcloud –database-ssl true–uuid –keystore /opt/vmware/vcloud-director/certificates.ks \
    –keystore-password “VMware1!” –primary-ip \
    –console-proxy-ip –console-proxy-port-https 8443Note that the keystore password is the inital appliance root password! We are still reusing appliance autogenerated self-signed certs at this point.
  • If this went right, start the vcd service and deploy additional nodes as needed.
  • On each node replace self-signed certificate with the CA signed.

Backup and Restore

The backup of the appliance is very easy, the restore less so. The backup is triggered from the primary node with the command:


It creates single tar file with database content and additional data to fully restore the vCloud Director instance. The problem is that partial restores (that would reuse existing nodes) are nearly impossible (at least in HA DB cluster scenario) and the restore involve basically the same procedure as was the case with migration.

CA Certificate Replacement

There are probably many ways how to accomplish this. You can create your own keystore and import certificates from it with cell-management-tool certificates command to the existing appliance /opt/vmware/vcloud-director/certificates.ks keystore. Or you can replace the appliance certificate.ks file and re-run the configure command. See here for deep dive.

Note that the appliance UI (on port 5480) uses different certificates. These are stored in /opt/vmware/appliance/etc/ssl. I will update this post with the procedure once it is available.

External DB Access

In case you need to access vCloud Director database externally, you must edit pg_hba.conf file with the IP address or subnet of the external host. However, pg_hba.conf file is dynamically generated and any manual changes will be quickly overwritten. The correct procedure is to create on the DB appliance node new file (with any name) in /opt/vmware/appliance/etc/pg_hba.d folder with a similar line:

host all all md5

Which means that any host from subnet will be able to log in via password authentication method with any database user account and access any database.

There is currently not an easy way to use network load balancer to always point to the primary node. This is planned for the next vCloud Director release.

Postgres User Time Bomb

Both vCloud Director 9.7 and appliance version have unfortunate time bomb issue where postgres user account will expire in 60 days (since the appliance creation, not its deployment). When that happens, the repmgr commands triggered via ssh stop working. So for example UI initiated failover with the promote button will not work.

The 9.7 appliance postgres user expires May 25 2019, appliance postgres user expires July 9 2019. The fix is as root on each DB appliance run the following command (see KB 70332):
chage -M -1 -d 1 postgres

You can check the postgres account status with:
chage -l postgres



Patching and Upgrading vCloud Director 9.7+ Appliance

Update 23/09/2019: The same process can be used to upgrade vCloud Director appliance to version 10. You can also use VMware patch repository if your appliances have internet connectivity. To reset the repo location from local to VMware provided just use the following command:

vamicli update –repo “”

vCloud Director patch has just been released and it is the first opportunity to patch the appliance edition of vCloud Director. Let me describe the process.

I have three appliance deployment with each node running the embedded database in active – standby – standby configuration. While in theory you could treat the appliance as regular Linux deployment and use the same patching process that was used for years by simply running vmware-vcloud-director-distribution-9.7.0-13635483.bin this would not patch just the vCloud Director binaries, but not the appliance packages. Therefore we must follow completely different process.

It should also be noted that currently we cannot use the automated orchestrated upgrade procedure or appliance UI. Hopefully both will come in the future as the appliance version matures.

Download the Appliance upgrade file: VMware_vCloud_Director_9.7.0.4264-13635483_update.tar.gz and unpack it to a transfer directory that is available to all the cells.

mkdir /opt/vmware/vcloud-director/data/transfer/update

tar xzf VMware_vCloud_Director_9.7.0.4264-13635483_update.tar.gz -C /opt/vmware/vcloud-director/data/transfer/update

Now on each cell we will have to set the repo, check if we need to update, shutdown the vCloud Director service and patch.

vamicli update –repo file:///opt/vmware/vcloud-director/data/transfer/update/

vamicli update –check

/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell -s

vamicli update –install latest

Note that during the whole process that embedded database is still running on each node, so until the vcd service shutdown of the last node the vCloud Director is still functional.

Once the last node is patched we can upgrade the database schema. Before we do that we will make a database backup. This is done from the primary DB node (which node is primary can be checked at the vCD Database Availability UI running on each node on port 5480).


The backup is created in the pgdb-backup folder in the transfer share (e.g. /opt/vmware/vcloud-director/data/transfer/pgdb-backup/db-backup-2019-05-20-090502.tgz).

Now we can finally proceed with the database schema upgrade:


If everything went right we can start vcd service on each cell and enjoy our updated vCloud Director instance.

service-vmware vcd start

vCloud Director Appliance – Phone Home Configuration

All VMware software contains Customer Experience Improvement Program (CEIP) feature also known as Phone Home.  You can read here what it does, but in general it sends VMware over the internet anonymized configuration, feature and performance data. VMware thus can track which features customer use or do not use, on what versions they are, which database, scale etc.

This is usually opt-in feature, so the user is asked during the installation if they want to enable CEIP. Below is a screenshot from vCloud Availability deployment.

However, during vCloud Director 9.7 appliance based deployment (as opposed to the binary interactive or unattended one) there is no configuration of this feature and it defaults to always enabled state.

In case you want to disable it, or see what it is actually configured to, use cell-management-command configure-ceip command on any of the cells (no service restart is necessary).

root@vcd1 [ ~ ]# /opt/vmware/vcloud-director/bin/cell-management-tool configure-ceip --status
Participation enabled
root@vcd1 [ ~ ]# /opt/vmware/vcloud-director/bin/cell-management-tool configure-ceip --disable
Participation disabled

What’s New in vCloud Director 9.7

With an impressive cadence after less than 6 months there is a new major release of vCloud Director – version 9.7. As usual, I will go into the new features from the technical perspective and provide additional links to related blog post in the future.

Just for reminder, you can find older What’s New in vCloud Director blog posts here: 9.5, 9.1.

Tenant User Interface Evolution

The legacy Flex UI is still here, but there is less and less reasons to use it. My guess is that 95% of the Flex features are ported to the HTML5 UI which also provides additional exclusive feature.

  • Branding: the service provider can now (with CloudAPI) change color scheme, theme, logos (including favicon and login page) and title not only globally but also individually for each tenant.  The provider can also add structured custom links and override existing links (help, about and standalone VMware Remote Console download). The custom links can also be dynamic with inclusion of (self-explaining) custom variables: ${TENANT_NAME}, ${TENANT_ID} and ${SESSION_TOKEN}
  • New ribbon offers quick glance on the content of all Organizations that logged in user has access to.
  • Recent Tasks pane provides immediate info about what is going on (last 50 items in past 12 hours)
  • Global search provides quick way to find particular object across VDCs or even sites:
  • vApp Network Diagram now shows vApp logical networking
  • Besides these large changes there are many small enhancements that level up tenant UI to nearly fully cover the legacy Flex UI. Users are actively encouraged to start using the Tenant UI with the yellow banner on top legacy UI:

Service Provider Admin UI

  • Service Provider Admin HTML5 UI adds access to Cloud Resources, vSphere Resources, Blocking Tasks to continue the process of adding features available from Admin Flex UI. Some items are still read only. On the other hand some (new) features are only available in the H5 UI: for example adding NSX-T Manager, Flex allocation model, etc.

New Compute Features

Flexible allocation model

The service provider can create (H5 UI only) completely new type of Org VDC – Flexible Allocation Model. The new model actually covers all the legacy allocation models (see here) plus provider can define completely new way for VMs and VDC to consume vSphere compute resources.

It is also possible to change allocation model of existing Org VDCs. For now that feature is possible only for Org VDCs created in 9.7 release though.

Compute Policies

While compute policies were already introduced in the previous release, the feature functionality is now enhanced and additionally simplified by including the tenant part in the H5 UI.

They are used to control resource allocation for example for licensing, performance or availability use cases. Provider defines (via vCloud Open API) policies that the tenant can then assign to deployed VMs.

Provider can for example define Microsoft Windows licensed hosts, create appropriate policy and assign it to Windows templates. Any VM deployed from such template will be placed only on those hosts.

Similarly provider can define high performance compute policy, which results in higher VM’s CPU limit and reservation. Tenant can chose and apply such policy for subset of her workloads.

Tenant could also use this feature to select site deployment for each particular VM for Org VDCs backed by vSphere Metro Cluster.

New Networking Features

Edge Cluster

The service provider has now the ability to control placement of each Org VDC Edge Gateway node (both for compute and storage) in order to get better resiliency and to secure higher SLAs. This functionality is available currently only through vCloud Open API (look for networkProfile). The provider first creates Edge Cluster by specifying resource pool and storage policy pair for primary and secondary Edge Cluster. Then the Edge cluster is assigned to Org VDCs. The Org VDC Edge Gateway nodes are automatically deployed into the Edge Cluster resource pools/datastores.

Legacy Edge deprecation

Org VDC Edge Gateways can no longer be deployed in the legacy mode (without advanced networking enabled). The existing legacy edges must be upgraded to advanced otherwise they are not manageable by vCloud Director. This is usually non-disruptive operation (unless they are still on version 5.5). The upgrade can be performed in bulk (or per org) with cell-management-tool commands:

./cell-management-tool edge-ip-allocation-updates --host <vcd-host> --user administrator --status
./cell-management-tool edge-ip-allocation-updates --host <vcd-host> --user administrator --update-ip-allocations

NSX-T Support

There is no new NSX-T related functionality other than the ability to register NSX-T Manager via UI and support for NSX-T 2.4 (Policy APIs).

SDDC Proxy

This is a completely new feature that allows using vCloud Director as proxy to a dedicated SDDC (vCenter Server with optional NSX). Provider thus can offer multitenant shared services together with dedicated infrastructure with direct access to its management components. vCloud Director becomes Centralized Point of Management (CPOM).

This is quite powerful feature and probably requires its own blog post, but briefly here is how it works.

The service provider deploys dedicated SDDC and register its vCenter Server into vCloud Director that is not going to be used for any Provider VDCs. Then with vCloud OpenAPI creates SDDC object pointing to the vCenter Server and publishes it to an organization. This will create SDDC Proxy which similarly as console proxy securely proxies the tenant all the way to the dedicated vCenter Server (UI/API management endpoints) without the need to expose it to the internet. Additional proxies can be added if needed for additional endpoints (NSX-T Manager, Site Replication Appliance, etc.). The proxying is configured in the users browser by downloading proxy configuration (PAC file) and is protected with time limited access token.

The SDDC appears as another tile in the Datacenter UI.

In order for the tenant to see the new tile type, CPOM extension must be enabled by the provided in the UI plugins (which now can be done from the UI).

vCenter Server published as SDDC is shown in the Provider Admin UI as Tenant published, VC used for PVDC is shown as Service Provider published.

It is possible to override limits, certificate security and ability to use vCenter Server both as SDDC and for VCD Provider VDC with vCloud API /api/admin/extension/settings/cpom.

The SDDC feature also introduces 3 new rights (View SDDC, Manage SDDC and Manage SDDC Proxy).


After the introduction of vCloud Director appliance in the 9.5 release, the new 9.7 appliance now provides not only cell functionality but also embedded PostgreSQL database which can be deployed in active – standby configuration, with synchronous physical replication and semi-automated failover provided by embedded replication manager and manually triggered through appliance ‘promote‘ UI. Usage of an external database with the appliance is no longer supported.

The appliance now uses two vNICs – eth0: Public Network for external traffic (and vCloud Director services such as UI/API, console proxy and internal messaging bus) the other eth1: Private Network for internal traffic – this is the one the embedded DB will use. It is recommended to use two different networks, however both vNICs can be also connected to the same network if that is the expected networking topology, but will need two IPs. Static routes can be configured easily.

Edit (2019/03/29): Correction, the two IPs must be from different subnets due to Photon routing firstboot issue.

It comes in three different sizes:

  • Cell only (no DB): 2 vCPUs, 8 GB RAM
  • Cell with embedded DB small: 2 vCPUs, 12 GB RAM
  • Cell with embedded DB large: 4 vCPUs, 24 GB RAM

Note that there is no DB only node. The cell services are running on all nodes and for high availability three nodes are the recommended minimum. NFS is still hard requirement for any appliance deployment (even with 1 node). Neither Cassandra DB (for VM metrics) nor RabbitMQ (for external integrations) are provided by the appliance and are still need to be optionally deployed.

vCloud Director binaries for non-appliance deployment are still provided but mixing of RHEL/CentOS nodes with appliance nodes is not supported. It is possible (but not that easy) to migrate your existing RHEL environment to appliance based one. The process requires upgrade to version 9.7 first and then migration so environments still using Oracle DB (which is not supported on 9.5 or 9.7) cannot go straight to embedded database and will need deployment of external PostgreSQL DB as intermediate step. Straight upgrade from 9.5 appliance version to 9.7 appliances is not supported and also involves migration.

Installation of certain agents (like vRealize Log Insight) into the appliance is supported as long as they are on the compatibility list but in general the appliance should be considered as a black box unlike RHEL/CentOS cells that can easily run additional software.

Backup of the database is triggered via create-db-backup command from the primary appliance. No automated backup scheduling is available at this time.


  • Microsoft SQL is still supported database for vCloud Director, but marked for future deprecation. PostgreSQL version 9.x is not supported, version 10 is now required.
  • API versions: 32.0, 31.0, 30.0, 29.0 supported, 28.0, 27.0, 26.0, 25.0, 24.0 23.0, 22.0, 21.0, 20.0 supported but marked for deprecation.
  • CloudAPI API Explorer has moved to new location (same as vCloud Director The user must log in to use a provider or tenant specific links:
  • Compatible fully supported Hashicorp blessed Terraform provider 2.1 has been released here accompanied with Golang SDK.
  • pyvcloud Python SDK and vcd-cli have been updated.
  • New vRealize Orchestrator vCloud Director plugin has been released.
  • Scalability and resilience enhancements of VC Proxy (listener) and StatsFeeder (used for VM metric collection). These services are now distributed across all vCloud Director cells (there is no longer 5 minute failover of the listener when the cell running it dies). This is also manifested by multiple VC connection alert emails during start up or VC reconnect action.