vCloud Director version 9.1 has been released. It has been just 6 months since the previous release (9.0) so VMware is delivering on its promise of multiple yearly releases in 6 months cadence.
In this whitepaper you can find high level overview of some of the new features. Let me summarize them and also provide additional ones here below.
H5 UI Enhancements
In iterative process the HTML 5 UI is slowly replacing legacy Flex UI. The tenant portion now includes vApp, Catalog and Networking management functionality, OVF/ISO download/uploads without the need for Client Integration Plugin (hooray!) and support for standalone VMware Remote Console.
Associated organizations from multiple or single (new in 9.1) vCloud Director instances now have aggregated view of all Org VDCs with seamless UI redirections between instances.
SDK for UI Extensibility has been released which means the service provider can extend the UI with additional sections to provide access to new services. The SDK includes very simple example of a static page extension (e.g. terms of service, links to other services or price lists) and upcoming vCAT-SP whitepaper will show how to do more complex ones.
The H5 UI is now also used in provider context but only for new features related to vRealize Orchestrator extensibility configuration.
Both legacy UIs (provider and tenants) are still available until the full feature parity is achieved.
vRealize Orchestrator Integration
Updated vRealize Orchestrator plugin has been released. This means both providers and tenants can automate and orchestrate repeating tasks in vCloud Director.
What is completely new is the ability to integrate any vRealize Orchestrator workflows into vCloud Director UI and essential provide XaaS (anything as a service). Similar to vRealize Automation XaaS.
Not specifically tied with vCloud Director 9.1 but fully supported now are:
vcd-cli Linux command line tool to easily trigger or script common vCloud Director tasks (both for provider and tenant).
Container Service Extension Ability to extend vCloud Director to be target for deployment of Kubernetes clusters for tenants and simple management through CLI.
Minor patch of vCloud Availability 2.0.1 was released last week. Besides many bug fixes, improved documentation and support for Cassandra version 3.x I want to highlight two undocumented features and add upgrade comment.
Provider vSphere Web Client Plugin
This is a return from 1.0 version of an experimental feature, where the provider can monitor state of vSphere Replication Manager Server, vSphere Replication Servers and all incoming and outgoing replications from inside the vSphere Web Client plugin in the particular (provider side) vCenter Server. This is especially useful for quick troubleshooting.
Complex vSphere SSO Domain Support
Although it is not recommended to have multiple vCloud Director / vCloud Availability instances sharing the same vSphere SSO domain, it is now possible to accommodate such scenario. The reason why it is not recommended is, that it creates unnecessary dependency between the instances, limits upgradability and scale of each instance.
Upon startup vSphere Replication Cloud Service (vRCS) is querying SSO Lookup Service for Cassandra nodes and resource vCenter Servers. In order to limit the scope of such query to only those that belong to the particular vCloud Availability instance, create text file /opt/vmware/hms/conf/sites on all vRCS nodes with SSO site names that should be queried (one line per site).
You can upgrade to vCloud Availability 2.0.1 both from version 1.0.x and 2.0, however you need to use different upgrade ISO images for upgrading of the replication components (vRMS, vRCS and vRS). The installer and UI appliances are redeployed fresh as they are all stateless.
This is a quick tip for those that want to run vRealize Orchestrator client on 4K screen in Windows 10 and cannot see anything because the font is so tiny and does not scale. The full credit goes to @joerglew who published in on our internal Socialcast but I have not seen it on public internet.
Almost 3 years ago I have published an article how to set up layer 2 VPN between on-prem vSphere environment and vCloud Director Org VDC.
As both vCloud Director and NSX evolved quite a bit since to simplify the whole set up, here comes the part II.
Let me first summarize the use case:
The tenant has an application that resides on 3 different VLAN based networks running in its own (vSphere) datacenter. The networks are routed with existing physical router. The tenant wants to extend 2 of these networks to cloud for cloud bursting or DR purposes, but not the 3rd one (for example because there runs a physical database server).
The following diagram shows the setup.
The main advancements are:
vCloud Director natively supports NSX L2 VPN (VCD 8.20 or newer needed).
NSX now (since 6.2) supports configuration of unstretched networks directly (no static routes are necessary anymore)
This means the full setup can be done by the tenant in self-service fashion
Here are the steps:
The tenant will deploy freely available NSX Standalone Edge in its datacenter connected to trunk port with 2 VLANs mapped (10 and 11). Additional network configuration is necessary (forged transmits and promiscuous mode or sink port creation – see the link)
In the cloud Org VDC tenant deploys two routed Org VDC networks with identical subnets and gateways as networks A and B. These networks must be connected to the Org VDC Edge GW via subinterface (there can be up to 200 such networks on single Edge). The Org VDC Edge must have advanced networking enabled.
Tenant enables and configures L2VPN server on its Org VDC Edge GW. Note that this is a premium feature that the service provider must enable in Organization first (see this blog post).
Before the L2VPN tunnel is established the following must be taken into account:
The Org VDC Edge GW IP addresses are identical with the on-prem existing physical router. Therefore Egress Optimization Gateway addresses must be entered in the Peer Site configuration. That will prevent the Org VDC Edge GW from sending ARP replies over the tunnel.
The same must be performed on the Standalone NSX Edge via CLI (see egress-optimize command here).
The non-stretched network (subnet C) must be configured on the Org VDC Edge GW so it knows that the subnet is reachable through the tunnel and not via its upstream interface(s). This option however is not in vCloud UI, instead vCloud networking API must be used. Alternatively the provider could configure non-stretched network directly in the NSX UI:
Finally, the tunnel can be established by configuring L2VPN server details on the on-prem Standalone NSX Edge L2VPN client (endpoint IP, port, credentials, encryption) and providing VLAN to tunnel mappings.
Note to find the Org VDC network subinterface tunnel mapping vCloud API must be used again:
In vCloud Director it is possible to configure vApp leases. The maximums are set by system admin at Organization level (in Policies), which can be lowered by Org Admin (at org level) and set by vApp owner at the vApp level. A vApp has runtime lease (for how long it will be in running state) and storage lease (for how long it will consume storage once it is not running).
vApp leases are very useful in test & dev or lab environments to make sure abandoned, unused VMs are not running and taking resources.
When vApp lease is coming to an end, its owner gets a reminder via email (how many days before expiration can be configured in User Preferences) and can optionally reset vApp lease to avoid its stopping or deletion.
By default expired running vApp is put into suspended state which means its memory content is saved to datastores. This ensures fully consistent state upon consequent power on of the vApp. This however make not be always needed especially in dev/lab situations – the memory content could take lots of storage space and for example saving 16 GB RAM VM to datastore could also create IO performance impact. As of vCloud Director 8.20 the Organization Administrator can instead change the default runtime expiry action to power off. The setting is done at Org level and must be done via API by setting the element <PowerOffOnRuntimeLeaseExpiration> of OrgLeaseSettingsType to true. The API version must be at least 25.0.