Archive for April, 2014

Update A CMDB As Part Of IaaS Machine Life Cycle

A good way of demonstrating VMware vCloud Automation Center 3rd party integrations is around a CMDB use case. The most obvious example will be to write to a DB table once the machine has been provisioned and then once again when it has been disposed of.

I am using vCAC 6.01 with the embedded vCO so I have the vCO SQL plugin already installed but if you are using an external vCO most probably you will need to installed the SQL plugin. It can be downloaded from here: Download

Next steps:

1. Make sure you have a DB to connect to and a DB table to write to. I have create a demo DB called ‘CMDB’ in an instance of SQL Server 2008 Express. Inside that DB I have a table called ‘machines’ with the following fields:


2. In vCO run the workflow ‘JDBC Workflow Generator’. This will help you form the JDBC URL you will need for the next step. As I am using SQL Express my URL looks like this:


3. In vCO run the workflow ‘Add a Database’. Use the JDBC URL generated in the previous step. If you still encounter difficulties then check that TCP/IP is enable: Launch the SQL Server Configuration Manager Click on the “Protocols for SQLEXPRESS” node, Right click on “TCP/IP” in the list of Protocols and choose, “Enable” Check that Static Port 1433 and NOT the Dynamic port is configured: Click on the “TCP/IP” child node, You will notice an entry on the right panel for “IPAll”, right click on this and select, “Properties” Clear out the value for “TCP Dynamic Ports” and Give a TcpPort number to use when making remote connections, i.e., “1433”.

4. In vCO run the workflow ‘Add a table to a Database’. Point to the table you have created before.

5. In vCO run the workflow ‘Generate CRUD workflows for a table’ and point to the table you have added to the DB in the previous step. You will need to specify in which vCO folder you want this workflow to be created. The workflow name will be something like “Create Active Record for ‘machines’ ” where ‘machines’ is the name of the DB table we have been working with all along.

6. Create a net new vCO workflow called ‘CMDB add machine Record’ for example. In it have a scriptable task to unwrap vCAC object properties and then call the “Create Active Record for ‘machines'” workflow to update the CMDB table:


I will add the workflow as an example at the end as a reference. In the workflow ‘General’ tab make sure you set the vCACHost parameter to point to your vCAC server as explained in my previous blog post 

7. Create a net new vCO workflow called ‘CMDB update machine Record’ for example. In it have a scriptable task to unwrap vCAC object properties as previously mentioned and then call the ‘Execute a Custom query’ workflow to update the CMDB table. The scriptable task in this workflow will look like this:

var timestamp = new Date();
System.log(“The timestamp is: ” + timestamp);
time = timestamp;
machine_state = state;
hostname = machine_name;
query = “UPDATE machines SET state= ” + “‘” + machine_state + “‘” + “,” + “timestamp= ” + “‘” + time + “‘” + “WHERE machine_name= ” + “‘” + hostname + “‘” + “;” ;
System.log(“Executing query ” + query + ” on database ” + );
rowsAffected = database.executeCustomQuery(query);
System.log(“Rows affected: “+ rowsAffected);

As you can see all we want to update is the machine state and timestamp columns with the state of the machine (now destroyed) and the time it has been destroyed.


In the workflow ‘General’ tab make sure you set the vCACHost parameter to point to your vCAC server as explained in my previous blog post  and also make sure the ‘database’ parameter is pointing to CMDB DB you are working with.

8. Now we need to associate these 2 workflows with a vCAC external Stubs. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in my previous blog post 

Make sure you associate your ‘CMDB add machine Record’ workflow with MachineProvisioned stub and  ‘CMDB update machine Record’ workflow with MachineDisposing stub as described in my previous blog post 

Job Done.

For your convenience the two vCO workflows mentioned above can be downloaded from here:


Yuval T


, , , ,


Application Aware High Availability – AppHA 1.1 is now Generally Available

vSphere App HA stands for “Application Aware High Availability”. It is a plug-in to the vSphere Web Client. App HA enables you to define high availability for the applications that are running on the virtual machines in your environment. Currently, vCenter Server allows users to define HA (High Availability) at the infrastructure level. The main use case here however is to make sure the application is Highly available. That means – consider the availability of the service (middleware). This is what AppHA is all about. Making sure that the service is up and if it’s not, try to restart it for several times, and then if necessary, call the vSphere HA API.

vSphere AppHA 1.1 Release Notes: Release Notes

Main use case is:

VI Admin wants to ensure high availability of the middleware:
  • Get alerts when service is down
  • Remediation through automatic restart of service and VM
Main advantages:
  • Simple to use
  • Adds another layer to currently working vSphere HA:
  • Integrated into vSphere web client
  • Integrated with vCenter Server (VC alarms)
  • Integrated with vSphere HA (Reset VM)
  • Works with vMotion

What’s new in AppHA 1.1:

  • More platform support: vSphere 5.5U1 & vSphere 5.1U2, ESX 5.1 & 5.5, NGC 5.1 & 5.5, Hyperic 5.8.1, Vmtools
  • You can create a custom AppHa service to manage non default AppHa services.
  • You can edit policies, including those that have already been assigned to services.
  • Translation for 6 languages
  • Services Supported by vSphere App HA – Out of the box support for of Oracle and Postgres.

All Services now supported by AppHA are listed here: Services

This release is part of:

  • vSphere 5.5 UP1 Enterprise +
  • vCloud Suite 5.5 UP1 Standard
  • vCloud Suite 5.5 UP1 Advanced
  • vCloud Suite 5.5 UP1 Enterprise
  • vS w/Ops Mgmt Enterprise + 5.5 UP1
How the product interacts with other VMware products:
  • Hyperic: App HA backend is actually VMware Hyperic server. Hyperic server and agents are responsible for monitoring the availability of the services and remediates them.
  • vSphere: VC alarms – when the user configures to fire VC alarms (in case service is down), App HA creates a VC alarm based on an event that Hyperic creates when the service is down.
  • vSphere: NGC – App HA is a plugin to NGC
  • vSphere HA – Resetting the VM is based on vSphere HA API. For that to work the requirements are: ESX 5.5/5.1, running VMtools and Configuration of vSphere HA on that cluster.
List of Network port needed for each component:
  • 5432 – App HA Postgres DB
  • 22- Port for enabling SSH access to the vSphere App HA virtual appliance •
  • 7443 – Communication with vFabricHyperic server. NOTE This port can change because it is dependent on what you select during the installation of the vFabricHypericserver.
  • 8443 – Port for the REST API.
More information can be found in the AppHA 1.1 documentation landing page: Landing Page

, , ,

Leave a comment