Let us start with the “important” announcement – a name change. vCloud Director has been re-branded to VMware Cloud Director. Fortunately we keep the same (unofficial) acronym – VCD. The current version is 10.1 which might look like a small increase from the previous 10.0 but that is just marketing numbering so do not put too much emphasis on it and assess yourself if it is big release or not.
has added support for NSX-T 3.0, but vSphere 7 support is missing. It is expected to come shortly in a major patch release (correction, NSX-T 3.0 did not make it yet too). You can upgrade your management clusters and dedicated vCenter Servers, just not those that are backing Provider VDCs.
As previously announced, no more Adobe Flex UI (cannot be even enabled with a secret switch). Shouldn’t be an issue however, as the HTML 5 UI has not only 99.9% parity but in fact is significantly better than Flex UI ever was. There are new features such as VM sizing and VM placement groups, advanced filtering, multiselect actions, badges, quick access to VM console or network cards, tasks and events in vApp details, Org VDC ACL, live import from vCenter Server, …
The UI team is no longer in feature parity mode, they are in make-it-better mode and doing a great job as can be seen from the screenshots below.
Certificate validation is now required for VC/NSX endpoints and will be required for LDAP in the next major release as well. It means your endpoints either have to have publicly trusted certificates, or you have to upload their signing certificate, or you have to approve their certificate on the first use (when you add or edit such endpoint). To ease the transition from older vCloud Director releases, you can run cell-management-tool trust-infra-certs command after upgrade that will automatically retrieve and trust certificates of all connected VC/NSX endpoints. If you forget to run this command, Cloud Director will not be able talk to VC/NSX endpoints!
While you still can use the Linux installer of Cloud Director with external database the appliance deployment factor has been again improved and there is less and less reasons not to use it especially for green field deployments.
The appliance API (on port 5480) has been enhanced to monitor status of services, to see which node is running active node of embedded database (useful for load balancing access to the database for external tools), monitor filesystem storage and trigger database node switchoever (planned failover) or promotion (after failure).
The appliance embedded appliance has for the first time automated failover functionality. It is disabled by default but you can enable it with the API.The Appliance UI has also been improved and provides some of the API functionality.
As you might know, Cloud Director has embedded messaging bus for inter-cell communication. In the past it was using ActiveMQ (ports 61611 and 61616). If the service provider wanted to use blocking tasks, notifications or vCloud API (or is it now VCloud API?!) extensions then an external RabbitMQ messaging bus had to be deployed. In the current release ActiveMQ has been replaced with Artemis and is also available externally for
blocking tasks and notifications, so RabbitMQ is no longer needed for these two use cases (Update: blocking tasks did not make it into this release). Additionally it can also be used by tenants.
Artemis uses MQTT communication protocol and the connection to it can be made via WebSocket session which is authenticated with regular Cloud Director authentication token mechanism.
Note that external RabbitMQ is still supported and still needed for vCloud API extensibility use case.
I have written full article on this feature here.
NSX-T integration has been enhanced with routed Org VDC networks (previous release supported NAT-routed) with BGP routing protocol. This feature currently requires dedicated Tier-0 Gateway for the tenant.
IPSec VPN is now in the UI (pre-shared key authentication and policy based are supported). IP Sets and Security Groups have been split with support for network objects that dynamically refer to all connected VMs.
The service provider can configure multiple NSX-T Edge Clusters and select which one will be used for a particular Tier-1 (Org VDC) Gateway. This enables separation of Tier-0 and Tier-1 Gateways to different Edge Clusters.
The NSX-V side of networking has also one new feature – you can now use Cross VDC networking within the same vCenter Server. This for example enables multi egress networks within single Org VDC for stretched cluster use case.
Edit (14/4/2020): Each NSX-V backed Org VDC Edge GW can now be placed to a specific cluster via API, which might be useful for the above use case. Previously you had to have same Edge Cluster config for the whole Org VDC.
vSphere VM Encryption is now supported within Cloud Director. The encryption happens in the hypervisor which means the data is encrypted both in rest as well in flight. The encryption is set up via vCenter Server storage policies by enabling host based rules. A compatible external key management server must be deployed and connected to vCenter Server. It means the feature is fully in realm of the service provider and key management is not exposed to tenants.
- Proxying of dedicated vCenter Servers (so called Centralized Point of Management – CPoM feature) was improved with extra stats, more proxies and browser extension to simplify the usage
- Support for VM (UI) and vApp (API only) live migration between Provider VDCs
- Due to UI upgrade to Clarity 2+ custom themes will have to be recompiled
- The provider can enable promiscuous mode and forged transmits on VXLAN backed Org VDC network (API only)
- Blocking tasks for OpenAPI tasks.
- Cloud Director 10.1 is the first release that enables automated NSX-V to NSX-T migration. More on that in a later blog post.