vCloud Director 9.0 is here!

On September, 28th VMware has released vCloud Director 9.0 for Service Providers.

This release brings a lot of interesting new features on both the Service Provider and Tenant side.

Here’s the list of the new features:

Service Provider Features

Edge Gateways Placement

The Service Provider can now choose a specific Cluster or Resource Pool for Edge Gateways placement.

Network Pool creation option

When you add a Provider vDC, you have the option to create a default VXLAN Network Pool or to use an existing Network Pool. You can create a Transport Zone in NSX that aligns with all your Clusters, as a result you can select this Transport Zone when you add a new Provider vDC.

PostgreSQL support

PostgreSQL is now supported by vCloud Director 9.0, other than Microsoft SQL Server and Oracle.
Additionally, the Cell Management Tool can help you migrate from SQL Server or Oracle to PostgreSQL.

vCenter Guest OS and Hardware version consistency

vCloud Director 9.0 works more efficiently with vCenter to determine the hardware version supported for Virtual Machines.

vCloud-vCenter latency

The new supported latency between vCloud Director and the managed vCenter(s) is 100 ms.

Migrate Tenant between Storage Arrays

There are different cases where a Service Provider needs to migrate Tenant workloads to a different Storage (e.g. change in SLA, maintenance). Therefore, you can now live migrate all the Tenant objects (Virtual Machines, Catalogs, Images etc.) to a different Datastore.

Support for Virtual Volumes (vVOLs)

vCloud Director 9.0 adds support to Datastores that are created in vCenter using Virtual Volumes.

Tenant Features

New Tenant UI

vCloud Director 9.0 has a brand new HTML5 User Interface for Tenants. As a result, all the day-by-day operations like VM and Network creation has been extremely simplified.

Multisite Management

Tenants can manage different Organizations from different vCloud Director instances from the new single unified HTML5 User Interface.

Distributed Logical Router

Tenants can now create DLRs to route between different Organization vDC Networks.

Support for Trunked VLAN backed Networks

You can now create Organization Networks and External Networks backed by Trunked VLANs. Consequently, a Tenant can leverage Virtual Guest Tagging (VLAN tagging in the Guest OS).

Security Groups

vCloud Director 9.0 introduces Security Groups that help define security policies dynamically. As a result, a Tenant Admin can define a criterion to match individual Virtual machines via Security Groups and DFW policies can be applied to these Security Groups.
You can find all the information here:
vCloud Director 9.0 What’s New

NSX Load Balancer AutoScale Automation Tool

The NSX LB AutoScale Automation Tool is a PowerNSX script developed by Dimitri Desmidt, NSX Senior Technical Product Manager @ VMware.
The tool is opensource and you can find it on VMware PowerNSX Github:
It’s super-easy to configure but very powerful.
In an environment based on vCenter and NSX-v, you can easily leverage this tool to auto-scale (growing and shrinking aka “Elastic LB”) your load balanced pools of VMs based on their load.

What the script does?

  • It checks the load (CPU and RAM) on all LB Pool members;
  • If the load is above a threshold:
    • vCenter Server deploys a new VM (from a template configured like the LB Pool members);
    • NSX Manager adds this new VM to the LB Pool as a new member;
  • When the load is below a threshold:
    • NSX Manager removes a VM from the pool;
    • vCenter Server deletes the VM.

To test the tool I want to use a 3-tier application made by 2 load balanced Web Servers, an Application Server and a DB Server.
I’ll artificially create load on one of the Web Servers to trigger a condition where the AutoScale Tool will deploy a new VM and add it the LB Pool.
As a second step, I’ll reset CPU load to a normal condition to trigger the deletion of the new VM.

This is the high-level architecture of my infrastructure for the 3-tier app:

To leverage the AutoScale Tool, it is important to note the relevant objects in the vCenter inventory.
We will use these elements to configure the PowerNSX script later.

My 3-tier App is hosted in a vSphere Cluster named “Compute Cluster A“.
In the following screenshot you can see the VMs that make the App: 2 Web Servers, 1 Application Server and 1 Database Server.
Highlighted you can see the 2 Web Servers, web-01a and web-02a, members of the Load Balancer Pool we’ll monitor and extend when needed using the AutoScale Tool.

A template VM, configured like the Web Servers already members of the Load Balancer Pool, has been prepared and will be used as a baseline for all new LB Pool members when needed.

The Edge Gateway providing the Load Balancing Services for my 3-tier App is named “OneArm-LoadBalancer-01“.

I’ve configured a Load Balancing Pool named Web-Tier-Pool-01. The 2 Web Servers of my application, web-01a ( and web-02a (, are configured as members of the Pool.
In my scenario, the Load Balancing algorithm has been set to Round Robin, but this doesn’t affect the behavior of the Tool.

The Web-Tier-Pool-01 LB Pool is configured as the default Pool for the Virtual Server Web-Tier-VIP-01. The configured Virtual IP is
My application is registered in the DNS as webapp.corp.local, resolved in the Virtual IP address of the LB Virtual Server.

Access to the application shows me that the Web Server web-02a is serving my request.

To test the AutoScale Tool, I artificially create a 100% CPU Usage on web-01a. The expected behavior is that the AutoScale Script will detect the anomaly and will trigger the deploy of a new Web Server that will be added to the Pool.

The Script can be easily scheduled to run as frequently as needed (for example every 1 minute), check the Load Balancer pool members performance and trigger the needed action.

The AutoScale Script is structured with a custom section where you can configure all the needed variables to connect to your environment and define the expected behavior.
The expected settings are very well explained, you can see the details in the following screenshot where I’m showing my configuration.
Note the name of the target Compute Cluster, the name of the Template VM, the name of the Edge Gateway, LB Pool and LB Virtual Server are the one I’ve highlighted in my vCenter and NSX inventory screenshots.

Let’s wait for the next scheduled run.
The Tool detects an 87% average load on web-01a CPU and trigger the creation of a new VM named Web_Clone1.

Here you can see the vCenter task that is creating the Web_Clone1 VM deploying it from the template named Web-Template.

The Script ends with the addition of the new VM to the Load Balancing Pool for my 3-tier application.
I’ve configured the script for a maximum of 3 Pool members and a minimum of 2, this means that starting from the next run it will monitor for the need to shrink the Pool if load will decrease, but it will not add any additional member even if I’ll have additional load. This configuration can be easily change editing the $VM_Min and $VM_Max variables.

Here you can see the additional member (Web_Clone1) added to the LB Pool.

Access to the application shows me that Web_Clone1 is actively serving content for my App.

On the next run of the Tool, web-01a CPU usage is still high. No actions are triggered because my $VM_Max variable is set to 3.

At this point I stop the process causing CPU load on web-01a and wait for the next run of the Tool.
As soon as CPU load is below the threshold, the removal of Web_Clone1 from the LB Pool and its deletion from vCenter are triggered.

My 3-tier App is now back in normal state with 2 Load Balanced Web Servers.

Conclusion: if you’re looking for a simple and very powerful way to manage the Auto-Scaling of your load balanced workloads in a vCenter+NSXv environment, you definitely have to try the NSX Load Balancer AutoScale Automation Tool.