This topic has been moved online many times, but always worth remembering and refresh knowledge. Especially that new versions appear every now and then, often differing from each other quite a bit. Besides, is that vCloud Director is treated with a slight reluctance by VMware, does not mean that everyone suddenly moved to vCAC. Additionally, I will focus here quite heavily on the balancing traffic to access virtual machines through the Console Proxy (vmrc). On this subject it is difficult to find comprehensive information.

In the first step, if you do not have, we need to generate the next cell for vCloud Director. All cell have to share, via NFS, the directory “transfer” (/opt/vmware/vcloud-director/data/transfer), so you need to think about where it was exported/mounted. This may be an external NAS server or directory exported from the first cell (in my case). Personally, I am running CentOS 6.4 as a platform for vCloud Director (instead of Red Hat), it makes easier to administration. Preparing the next cell is very simple, just clone the first one! Of course, the first time we run it in network isolation mode, turn off the vCD (service vmware-vcd stop), reconfigure the network card to the new IP address and enable network. On the first cell (our CentOS), if we do not have, install and run the NFS server:

yum install nfs-utils nfs-utils-lib
chkconfig nfs on
service rpcbind start
service nfs start

To /etc/exports we add the line:

/opt/vmware/vcloud-director/data/transfer       IP (rw,sync,no_root_squash,no_subtree_check)

And issue the following command: exportfs -a

At this point, we have exported NFS directory “transfer”. Copy the file  /opt/vmware/vcloud-director/etc/responses.properties (it contains a basic configuration that will be used by the next cell) to it. Now go into the preparation of SSL certificates for both nodes. This is a very important step and must be done correctly. Why do we need to make modifications to both cells? Because according to this KB, if we want to balance VMRC traffic connections, all cells should be shared SSL certificate for the Console Proxy. The host name in the certificate must match the vCD entry of public console proxy name:

Otherwise we can meet up with the error “Exception during handshake: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown”. As always, the best solution is to have a wildcard certificate (pkcs12 format). Prepare certificates.ks based on pkcs12 (.pfx) is very simple:

Create empty keystore JCEKS:

keytool -keystore certificates.ks -storetype JCEKS -storepass xxxxxxx -genkey -keyalg RSA -keysize 2048 -alias http

keytool -delete -alias http -keystore certificates.ks

Import Root and Intermediate CA certificates (as many as you need, the alias name can be eg. Intermediate1, intermediate2 etc):

keytool -storetype JCEKS -storepass xxxxxxx -keystore certificates.ks –importcert –file ca1 –alias root

keytool -storetype JCEKS -storepass xxxxxxx -keystore certificates.ks -importcert -file ca2 -alias intermediate

And import a wildcard certificate with the key:

keytool -v -importkeystore -srckeystore pulab.pfx -srcstoretype PKCS12 -destkeystore certificates.ks -deststoretype JCEKS -alias http

keytool -v -importkeystore -srckeystore pulab.pfx -srcstoretype PKCS12 -destkeystore certificates.ks -deststoretype JCEKS –alias consoleproxy

And all this, on both cells disable vCloud Director service (service vmware-vcd stop), remove the old keystore file and run the /opt/vmware/vcloud-director/bin/configure. The program will detect the file change and proposes to use the new configuration. After running up the two cells should we see the following result:

At this point, we can go to the F5 console. Prepare the appropriate configuration will start by creating the appropriate monitors, one for vCloud Director and the other for the Console Proxy:

In the next step we create persistence profile for vCD, Console Proxy does not need such a profile (we have two ways, cookie or source_addr):

Now create a SSL profile for vCD, in our case we use, as usual, the same wildcard profile:

Add more Nodes (at this stage ICMP is sufficiently monitor):

Create the first pool for vCloud Director:

Create a second pool for Console Proxy:

At this stage, we have everything that is needed to create virtual servers. Be the first to create a VIP for vCloud Director:

This is the standard set for the web server, use the http profile allows you to use the security policy (ASM) in access to vCloud Director. Using SSL profile is not obligatory, we can make a full SSL transparent session to cells (if we have the same certificate for all). If you do not use directory synchronization between different clouds, you can use a separate SSL certificate signed by the local CA for each single node (and use SSL profile on F5). The last step is to create a VIP for the Console Proxy:

In this case we do not use the http profile, Console Proxy is not simply an HTTPS service.Therefore, we can not use the ASM for her! vCloud Director is a good piece of software and it’s worth to use it :-)