Category: Cloud computing

November 17th, 2017 by axel

Just a little reminder about the configuration of vRA


Tenant creation (System administrator privilege required for this operation)

  • Create local users and assign Tenant Admin permission

Tenant configuration (Tenant administrator privilege required for this action)

  •  Add a directory to bind an AD domain
    • To enable HA, add a Identity Provider using this time the second vRA node as a connector and the VIP of the vRA node as the new hostname.
  • Create custom groups (System or tenant administrator privilege required for this action)
  • Assign IaaS All needed rights (including tenant admin, IaaS archi, at least)
  • Provide IaaS administrator privilege to the newly created custom group
  • If needed, plan access policies (to set network range to allow authentication etc…)

Create endpoint (tenant administrator privilege required for this action)

  • name must match with the agent name installed on IaaS server
  • Restart vcac vCenter agent to force an inventory of vCenter resources
  • Compute resource must be available once data have been collected

Make sure that no error appears in IaaS logs :

  • On the server in c:\program files (x86)\vmware\vcac\server\logs\error.log
  • On the portal, as a IaaS admin, you can go to Infrastructure > Monitoring > Log
Tips : If cluster storage does not appear, you can think about an issue with MSDTC between SQL and IaaS


  • Create a Fabric Group (IaaS administrator privilege required for this action)
    • Select Fabric group administrators
  • Create a Machine Prefix (Fabric Group administrator privilege required for this action)
  • Create a business group (Tenant administrator privilege required for this action)
  • Create a reservation for the business group (Fabric Group administrator privilege required for this action)
    • Make sure this new reservation is enabled (it is by default)
    • Provide a machine quota, RAM, Storage, Network

Blueprint creation (IaaS Architecte privilege required for this action)

  • Publish it to make it visible as a catalog item

Catalog creation (Tenant administrator privilege required for this action)

    • Create a catalog service
      • Make sure it is active (by default)
    • Add a catalog item
      • Select a blueprint to make it available to link it to the proper service
    • Entitle users for the new catalog
      • Make sure the status is active (draft by default)
      • Select a business group (revert no permitted on this setting once the entitlement has been saved)
      • Select group and users
      • Select service, catalog items and allowed actions on them

Test and enjoy 🙂

Posted in Cloud computing, Virtualization Tagged with: ,

October 12th, 2017 by axel

This post is just a kind reminder of the installation steps of VRA in a distributed mode.

What you will have to do

  • Deploy (not configure) the vRA appliance instances
  • Configure the load balancer for vRA in a minimal mode (TCP monitoring and only one  server active in pools in order to freeze the network flows between  the same vRA and IaaS instance)
  • Create certificates with a SAN containing all the FQDNs used in your architecture :
    • vra vip
    • iaas web vip
    • iaas manager vip
    • vra instances
    • iaas web instances
    • iaas manager instances
    • orchrestrator if used
  • Configure the first vRA appliance :
    • NTP
    • Certificates
      • Import successfull but certificate attached to default web site is still the default one (issued byVMware).
    • SSO (administrator password)
      • At this step, vRA default web site is created and a license can added.
      • log can be found in /var/log/vcac/vcac-config.log
      • web services start-up can be tracked in catalina.out log file.
      • At this step, vcac website must be available and vra node must respond on 443 port.
    • License
    • Disable CEIP in telemetry tab
    • At this step and according to vRA installation guide, vRA website should be available (with or without any license). Not in my case.
      • Error 400
        • All services are started !
        • Shutdown node 1. Started node 2 and run the same configuration steps : certificates (this  time not  in lb mode and with self-signed certificate), NTP, SSO.
        • Ok, default  tenant  website  available.
        • After some troubleshooting, it turned out that my edge was misconfigured on the LB part. See this post.
      • Blank page
        • Just forgot,as an idiot, to enable Load balancer feature before configuring it.
  • Add the second vRA node (appliance) :
    • Configure the NTP with the same settings than the one provided for the first node.
    • In the LB configuration, enable the second node in the vRA pool
    • Power ON the first node and wait for the startup of the services
    • Join the cluster by providing the FQDN of the first node otherwise you will get an error on port 5480.
      • Once the node has been added to the cluster, web requests can be load balanced.
      • Disabling one server after the other does not prevent from accessing the vcac portal available
  • Disable useless services
      • vRO embedded server can be disabled.

    A few months ago, we used to read that vRO embedded could’nt run in production environments however I recently read that VMware now recommends embedded version for small/medium sized deployments. (found in vRO Cookbook second edition)

  • Install first IaaS node
    • Install signed certificates (import pfx in trusted root store + IIS => Do not bind so 443 port can be used by the installer)
    • download installation software from vRA
    • create db
      • Log can be found under IaaS node : C:\Program Files (x86)\VMware\vCAC\InstallLogs
    • Check related LB settings (no monitoring !, only one node active)
    • install IaaS Website et Model Manager
        • Failed : Certificate issue. At this step, just keep in mind that the LB certificate was in the Personal folder of the iaas and NOT in the Trusted Root one (was only visible in non-friendly view)
          • Retry with this certificate in both Personal and Trusted Root folders and under ServiceAccount session : ok
        • Help may be found there
        • At this step, you will need to use the vip for IaaS Web.

      VMware vCloud Automation Center Server and VMware vCloud Automation Center WAPI are now installed

    • Install Manager Service
      • Once again, the vip for IaaS Web will be required.
    • Install DEM (worker and orchestrator)
      • Here, vip will be needed for IaaS Web and IaaS Service Manager
  • Install necessary agent
    • Use strictly the same name on each IaaS node the agent will be installed on.


Somes considerations regarding vRA load balancing


vRA virtual appliances run concurrently in active/active mode.

For IaaS components, things go a bit different :

IaaS component LB Mode
Web site active/active
Model Manager Data  N/A just one instance, installed on the first (installed) Web site
Service Manager active/passive (however, a manual startup of the service on the second is necessary)
DEM Worker  active/active
DEM Orchestrator  active/active


Posted in Cloud computing Tagged with: ,

October 9th, 2017 by axel

Hi folks,

It’s been a long time since my last post.
Here I come with a new issue in vCloud Director Service Provider (8.10 but I think it’s applicable to more recent and previous versions).

Our platform consists of vCenter 6.0U2 (external PSC , tiny model), NSX 6.2.5 and vCloud Director SP 8.10.1.

A few days ago I faced a weird issue while I was trying to import a vApp template in my organization catalog :

“[xxxxx] Folder xxxx does not exist in our inventory, but vCenter Server claims that is does.”

Meanwhile, I was able to upload media files in the same catalog.

I observed the same results after running the same tests on all our catalogs and organization.


How the problem has been solved ?

I first thought it was due to a vCloud inventory issue. I forced a synchronization with vCenter without any improvement. I even cleared the INV tables in the vCloud database. Same result, still unable to upload vApp or OVF in the catalogs.

VMware support pointed out the issue without even requiring the support bundles.

This was actually a vCenter issue and not a vCloud one. Our vCenter was suffering of low memory.

vCenter did what vCloud asked but took too much time to inform to update the cell. This is the explanation given by VMware. A simple reboot should solve the issue.

To confirm the RAM problem, i simply ran the command “free -m” on our vCenter appliance, the output showed that the swap partition was heavily used, almost entirely, more than 20 GB. I do not mention the RAM  on purpose because it almost always consumes around 8 GB.

In this case, swapping very likely means that the vCenter has memory leaks…

A simple reboot could have freed the memory and flushed the swap partition.  I think so, however I decided to add some more RAM and adjust the VM to the small model. This, because our platform also backs vRA and a lot of other components that interact with vCenter.

After the reboot my upload issue was solved !


Good to know !

RAM Upgrade

Notice that as of the version 6 of vcsa, it is no more required to manually adjust the RAM dedicated to the JVM. The JVM memory is dynamically adjusted.

The famous William Lam (blog VirtuallyGhettto) talks about that in this post.

Disk sizing upgrade

Moreover, no need to manually resize all the file systems. A script checks the disks and volumes and resizes them automatically at the boot of the appliance. If the resizing occurs while the appliance is already running a simple command line does the job. W. Lam explains that too here.


If you want to get more information about the VCSA partitioning you can check this KB. 

Here, a reminder for the different VCSA sizing models.





Posted in Cloud computing, Virtualization, vSphere Tagged with: , ,

June 2nd, 2017 by axel

I could also have named this post “Why you should never purge the content of the staging folder of your cells” 🙂

As I was troubleshooting a problem for a customer, I faced an annoying issue :
I was suddenly unable to download specific vApps and was always receiving the following error from vCloud “Invalid response from server”.

Very interesting and crystal clear message, isn’t it ?!
My best option to figure out what was going on was to browse vCloud logs.
vCloud-container-debug.log file gave precious information that helped me to understand my problem.

Look at this :

Resource file: descriptor.ovf(2b448314-daf6-46dc-b7f1-84bb205f35c6). Download failed. Unable to locate resource file | requestId=da57dd71-aded-47e4-8d9d-93a64a8cab95,request=GET https://CellIPAddress/transfer/2a3ee224-60a8-4f64-b99b-84afade8f3e9/descriptor.ovf

The OVF descriptor of the vApp I wanted to download could not be found. vCloud was unable to know what to transfer to its client.

What is OVF descriptor ?
In a nutshell the OVF descriptor is a XML file that contains all necessary information about an OVF package (also used with OVA), its content (the VMs that make up the vApp) and how to download it. You can find more details about OVF format here.

I can guess a question rising in your head : Why vCloud is unable to find the files since we are simply trying to download an existing vApp template ? vCloud should already know the different templates it stores in its catalogs ! You’re right but …

Getting more and more confused, I started thinking about the last events and I remembered that some days before, I had manually purged the staging folder !
All the files were quite old (more than 2 weeks) and were supposed to be automatically removed. I thought – and I was wrong – that there was an issue with the cell.
What a big mistake !! Actually by manually deleting the content of the staging folder (/opt/vmware/vcloud-director/data/transfer) I accidentally broke the link between vCloud and its vApp download session.

At this time, I realized that I was missing something in the understanding of the download process and I decided to delve this particular topic.

This post will expose what I knew and learnt and also how VMware support team helped me to solve the problem. It will be articulated like that :

Overview of a vApp download
vApp download process
Cancelling a download
Problem resolution

Overview of a vApp download

When one downloads a vApp template two main steps are achieved :

1 – After clicking on “Download…” vCloud enables the vApp template for download.
Actually, enabling a vApp for download is not only changing a property from “False” to “True”, its also copying the vApp content in the staging folder. That’s why if you pay attention to the operation, you may feel that it is may be very long (depending on the size of the vApp).

2 – Once the enablement action is completed, the download from the client starts.

If you look at the picture below you will see that :

1. The vApp is being enabled for download in vCloud Director

2. In the same time vCenter is exporting the OVF template (the target folder is the staging folder !).

3. Nothing is happening in the browser transfer windows. It is totally normal. The transfer will process only once the OVF export will have been completed.

But behing this, several things are achieved : checks, db updates etc…

Behind the scenes

Let me give you some details about what really runs in background when a cell manages a download request.

I made the diagram below according to my understanding of the process. So feel free to tell me if something’s wrong.

Cancelling a download

Depending on when you cancel a download – during or after the enablement of the vApp – different exepected results are observed.

I drew another diagram to present them.

*About the transfer session time out value :
This value defines the period in course of which any interrupted transfer session can be resumed (without re-enabling the vApp).
Once the limit is reached, the data are deleted from the staging folder.

One can consider this value as the link between vCloud and a vApp download session (the famous I shouldn’t have broken).

You can find this value in the system settings of vCloud Director :

Problem resolution

In normal conditions an automatic cleanup of the DB should have been done in the DB but in my case, VMware support pointed out a time sync issue between the cells and the DB server. The cells were running 3 mns behind the DB server so the “CleanTransferSession” triggers could never be met.
VMware and I decided to first clean the DB and only after and for me, solve the time sync* issue.

To see the planned “CleanTransferSession” triggers, run the query :
select * from QRTZ_TRIGGERS where TRIGGER_NAME=‘GLOBAL_com.vmware.vcloud.transfer.server_cleanTransferSessionsTrigger’

To read the time value, use some timer converter website like

This manual DB cleanup relies on clearing records related to the download tasks plus – I think it is optional – the usual queries to clear QUARTZ and INV tables.

* This post will not show how to solve the time sync issue (ntpdate service misconfiguration here) but you can have a look at time keeping KBs :
For linux, timekeeping best practices are available here.
For winfows, the same there.

Clearing vApp download tasks

Of course, at this step run a backup of the DB before process with any records deletion !

Also notice that the procedure below is not supported by VMware and must not be followed without their support !

You first have to identify the records to delete. To do so, launch the query

select * from transfer_session

You will get something like this :

Then, for each transfer session (vApp download task), you must delete the relevant files.

select * from dbo.resource_file where spool_dir = ‘/opt/vmware/vcloud-director/data/transfer/2a3ee224-60a8-4f64-b99b-84afade8f3e9’ to confirm the content of a specific vApp and delete from transfer_session where transfer_session_id = 0x2A3EE22460A84F64B99B84AFADE8F3E9
delete * from dbo.resource_file and delete * from transfer_session can be run too of course but must be used with caution

You will have understood that dbo.resource_file.spool_dir = transfer_session.base_dir

Once all transfer sessions have been cleared, we can reset QUARTZ and INV tables.

As info or reminder, QUARTZ tables store information about vCloud processes and tasks and INV tables store data about vCenter inventory.
Among several reasons, we may have to clear them when vCloud objects status are not synced with their real status in vSphere.

Clearing QUARTZ and INV tables

Prior the resume, we have to stop the cell according. I deal with stopping vCloud in this post, under “Implement vCloud certificates” section.

QUARTZ tables


INV tables

DELETE FROM compute_resource_inv;
DELETE FROM custom_field_manager_inv;

DELETE FROM cluster_compute_resource_inv;
DELETE FROM datacenter_inv;
DELETE FROM datacenter_network_inv;
DELETE FROM datastore_inv;
DELETE FROM datastore_profile_inv;
DELETE FROM dv_portgroup_inv;
DELETE FROM dv_switch_inv;
DELETE FROM folder_inv;
DELETE FROM managed_server_inv;
DELETE FROM managed_server_datastore_inv;
DELETE FROM managed_server_network_inv;
DELETE FROM network_inv;
DELETE FROM resource_pool_inv;
DELETE FROM storage_pod_inv;
DELETE FROM storage_profile_inv;
DELETE FROM task_inv;
DELETE FROM property_map;


What we can keep in mind :

1 – Make sure that every component of your environment are time synced.
2 – Do not delete any file in the staging folder if the session transfer time-out value has not been reached.
3 – In case of remaining  folder, double check the transfer session time out value and the transfer_session table of the vCloud database before deleting anything in the staging folder.

At the time I am writing this post, I’m observing something weird : For some cancelled downloads and although there is no more transfer session record, transfer session folders still exist in the staging folder. For each of them, a partial vmdk file (20 MB) is visible and an error is logged in vCloud logs. I’ve opened a case at VMware for this. Meanwhile, I gonna check the vCenter logs too.

I’ll let you know asap.

PS :
I did not track it yet as I did for a vApp but I assume that the mecanism I described here are the same for another catalog item download. I will update later on this.

I will try to make another post for the upload process soon.

Fresh update regarding the remaining files after a download cancellation : VMware support confirm a bug and will try to fix it for version 9 of vCloud, expected by july (2017).

Posted in Cloud computing, Virtualization Tagged with: ,

March 5th, 2017 by axel

I assume at this step that you already know the vCloud component architecture.

This post aims at describing the different steps to follow when it comes to replace vCloud Director SSL certificates and configure the load Balancer (Netscaler in this post).

We’ll see how to :

  1. Create the Private Key
  2. Create the CSR
  3. Check the signed certificates
  4. Implement the certificates in the cells
  5. Export the keystore for the load balancer, Netscaler in my case.
  6. Import the keystore in Netscaler.
  7. Bind the certificates to the Virtual Server.
  8. Configure vCloud public URLs


Open a SSH session as the root user on the first cell and go to /opt/vmware/vcloud-director/jre/bin.

Then, run the following two commands to generate respectively http and consoleproxy private keys. Enter a name for a new keystore so you can revert (do a rollback) in case of any failure during the certificates replacement process

./keytool -keystore keystoreName.ks -storetype JCEKS –storepass password -genkey -keyalg RSA -keysize 2048 -alias http

       ./keytool -keystore keystoreName.ks -storetype JCEKS –storepass password -genkey      -keyalg RSA -keysize 2048 -alias consoleproxy

Please notice that the aliases  cannot be customized and must be http for the web portal service and consoleproxy for the VMRC console proxy service.

You will be prompted and will have to provide information to build the DN of the certificate.

At the question “What is your first and last name?“, type the FQDN of either the cell or the load balancer virtual server.
For exemple for http service and for consoleproxy service.


It is time now to create the certificate signing request for each service. As vCloud Services will be load balanced, the certificates must be done for the public adresses of vCloud Director.

Still from the same SSH session and the same folder, enter the following commands to start the CSR creation wizard :

  • For the http service :
 ./keytool -keystore keystoreName.ks* -storetype JCEKS –storepass password -certreq -alias http -file outputFile.csr
  • For the consoleproxy service :
  ./keytool -keystore keystoreName.ks* -storetype JCEKS –storepass password -certreq -alias consoleproxy -file outputFile.csr
*Both http and consoleproxy certificates must share the same keystore !

Once both web and console proxy services CSR have been done, we have to transmit them to the team in charge of issuing the certificates.


The certificates have been delivered. Before importing them in vCloud, we should check that they are correct.

Ensure that in the Subject propertie, the Common Name (CN) value is the public FQDN of the service. For exemple for http service.


Once checked, they must be imported according the following order :

Root  => Intermediate (if any) => http and consoleproxy (for the last two, the order doesn’t matter)

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import –alias root –file RootCertificate.cer

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import –alias intermediate –file IntermediateCertificate.cer

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import –alias http –file httpCertificate.cer

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import -alias consoleproxy –file consoleproxyCertificate.cer

We can now list the content of the keystore and verify the registered certificates

 ./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –list

Last step, reconfigure vCloud application to take in account the new certificates

Stop the application

If they have been properly issued, we have to gracefully stop the vcloud services on the first cell. To do so, go to folder  /opt/vmware/vcloud-director/bin and run the following commands :

  • ./cell-management-tool cell -u administrator -p password  –status to verify the current jobs status
  • ./cell-management-tool cell -u administrator -p password –quiesce true to prevent any new task from being started
  • ./cell-management-tool cell -u administrator -p password –shutdown to shutdown the cell
  • service vmware-vcd status  to ensure that vCloud services are effectively stopped.

Register the new certificates in the application

Launch the configuration tool : /opt/vmware/vcloud-director/bin/configure*

Give the path of the new keystore and the relevant password

Once the database updated, you are prompted to start the service, accept.

Copy the new keystore on every other cells and repeat steps “Stop the application” and “Register the new certificates in the application”.

!! For security reason, it is recommended to move the keystore file in a secured place (out of the cells).
Moving the keystore doesn’t affect the cell behaviour. During a “configure” operation, a binary file is created for each certificate (saved as certificates and proxycertificates files) in folder /opt/vmware/vcloud-director/etc.
* For some unknown reason, sometimes the path for the keystore is not prompted. When this occurs, just :

Edit the file /opt/vmware/vcloud-director/etc/ and comment the lines related to the existing keystore path and password :

user.keystore.path = xxxxx

user.keystore.password = xxxxx

Relaunch the configure tool.


In order to implement load balancing of vCloud Director on Nestcaler we have to :
– Export the private key of each certificate.
– Get a copy of the root and if any, the intermediate certificate.

From a SSH session (as a root user) on one cellule, go to the folder /opt/vmware/vcloud-director/jre/bin

Run the command

 ./keytool -v -importkeystore -srcstoretype JCEKS -srckeystore /App/install/backup/NewSignedCertificates.ks -srcalias http -destkeystore /App/install/NewSignedCertificates.p12 -deststoretype PKCS12

This command will export the certificate of the web portal service and its private key

You will have to provide a password for the new keystore (the P12 one that will be generated)and the password of the existing keystore ( the JCEKS one) As the monitoring of the console proxy is done on the TCP socket, we do not have to export de consoleproxy private key and certificate.

We can now verify the content of the p12 keystore with the command

We can see that the private key is available !

Next step :
Import the certificate and its private key in the Netscaler keystore.


From your Netscaler interface (default credential are nsroot/nsroot at least til version, the one i used for this post)

First check that the CA Root certificate is installed in Netscaler.

=> Go to Traffic Management >> SSL >> Certificates >> CA Certificates

Then, add you server certificate

=> Go to Traffic Management >> SSL >> Certificates >> Server Certificates

=> Click on Install button

Type an explicite name for the certificate

Locate your certificate and provide the password of your keystore.

You can now install the certificate

Your certificate is now available in Netscaler and can be added to a virtual server.

Next Step :
Bind the new certificate to the vCloud HTTPS* virtual server.

*You might be confused because the alias of the certificate is “http” but just keep in mind that HTTP requests are redirected to the HTTPS port of the cell.


Once the vCloud http certificate has been installed in Netscaler, we have to link it to the vCloud HTTPS virtual server.

A procedure to implement vCloud load balancing in Netscaler is available here.

=> Go to Traffic Management >> Load Balancing >> Virtual Servers

Select your vCloud Virtual Server

Look at the state : Red because the virtual server does not have any server certificate

In the Certificate section, click on No at the line “No Server Certificate” so you can add the new certificate.

Then select the appropriate certificate and click on the Select button (no need to click on install as we’ve already installed it just before)

Finally, bind it.

Notice at this step that if you have not already bound the CA certificate you will have to add it too. (just click on No at the No CA Certificate)

Once the bind has been done, we can validate the virtual server modification by clicking on “Done” button at the bottom of the page.

You can now notice that your Virtual Server is now displaying a green status

Let’s now try to connect to vCloud using the virtual server FQDN

If you have a security alert, just ensure that the Root CA certificate id installed on your computer and that you typed the right URL (must match with the subject (or common name) of the certificate)


Below an example of a typical configuration. Make sure to respect the format of the information you provide.

Posted in Cloud computing Tagged with: ,