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).

Appliance

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.

Other

• 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 9.5.0.2). The user must log in to use a provider or tenant specific links:
  /api-explorer/provider
  /api-explorer/tenant/<org-name>
• 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.