If you follow me on Twitter or Google+ probably have seen and increased number of tweets and posts about OpenStack, DevStack, KVM and other Linux related topics. It’s no secret that I am a *nix guy however it wasn’t until last year that I really discovered OpenStack. Oh yes I knew about it, have read a ton of articles and watched some videos in YouTube but I never had the opportunity to actually play with it until I sat on a Hands on Lab about OpenStack and vSphere during VMworld in Barcelona last October. After VMworld I started a personal project to learn as much as possible about OpenStack, using some labs with KVM and vSphere to try to achieve a decent level of proficiency. Finally this year I was able to ramp up with NSX and decided to build a new lab with OpenStack, KVM and NSX and document my progress here in my blog. So without further ado here it is my first series of posts about OpenStack and NSX.

During this series we will see how to deploy OpenStack with KVM as the underlying hypervisor and VMware NSX for the networking part. I intended to create a fairly comprehensive guide here for my personal reference and as a learning exercise. All posts of the series are based on my personal experience in a lab environment.

Lab components

To illustrate the post I have created a lab with virtual machines running on VMware Fusion in my MacBook Pro, but you can use any virtualization software you want as long as it allows you to expose the virtualization extensions to the virtual machine, for the KVM compute node. We will need the following virtual machines

  • Cloud controller node
  • Nova compute node with KVM
  • Neutron networking node
  • GlusterFS storage node
  • NSX Controller
  • NSX Manager
  • NSX Service Node
  • NSX Gateway

I’ll provide the exact hardware config of each virtual machine in its own part. We will deploy OpenStack Havana using as reference one of the architectures described in OpenStack Havana installation guide.

You are probably asking yourself now why I’m using Havana when Icehouse was released just a few weeks ago? There are two reasons for this, first is that when I started to create my lab and decided to document my progress here Icehouse wasn’t out yet and after it was released I decided to stick with Havana because the NSX plugin for Neutron, OpenStack network module, has not been updated yet for Icehouse.

The software versions to be used are:

  • OpenStack Havana
  • CentOS 6.4 – For OpenStack nodes
  • Fedora 20 – For GlusterFS storage node
  • NSX for multi-hypervisor

I have another Fedora 20 virtual machine providing DNS and NTP services for the lab, I’m planning to add DHCP and OpenLDAP capabilities in the future.

NSX deployment overview

Screen Shot 2014-04-24 at 22.40.40The Network Views

The first concept you need to understand in NSX are the network views. NSX defines two network views:

  • Logical Network View
  • Transport Network View

The Logical Network View is a representation of the network services and connectivity that a virtual machine “see” in the cloud, basically for the operating system running inside the VM the logical network view is “the network” that it is connected to. The Logical Network View is completely independent from the underlying physical network. It is made of the logical ports, switches and routers that interconnects the different virtual machines within a tenant and connect them to the outside physical network. In a cloud each tenant will have its own logical network view and would isolated from other tenants views.

The Transport Network View represents the physical devices that underlie the logical networks. These devices or transport nodes, as they are referred, can be hypervisors and the network appliances interconnecting those hypervisors to the external physical network. Every one of these transport nodes must run an instance of Open vSwitch.

NSX Deployment Components

An NSX deployment will be made out of the Control Plane and Data Plane. Additionally there is a Management Plane comprised by the NSX Manager, last one is not mandatory for an OpenStack deployment but it can be useful.

NSX Control Plane

The Control Plane is made of the NSX Controller Cluster. This is an OpenFlow controller that manages all the Open vSwitch devices running on the transport nodes and a logical network manager that allow to build and maintain all the logical networks carried by the transport nodes. It provides consistency between logical network view and transport network view. Internally it has several roles to manage the different tasks it is responsible of.

  • Transport node management: Maintains connections with the different OVS instances.
  • Logical network management: Monitors when endhosts get connected and disconnected from OVS. Also implements logical connectivity and policies by configuring OVS forwarding states.
  • Data persistence and replication: Stores data from OVS devices and NVP API to provides persistence across all nodes of the cluster in case of failure.
  • API server: Handles HTTP requests from external elements.

The NSX Controller is an scalable out cluster running on x86 hardware, it supports a minimum of three nodes and a maximum of five. Single node clusters are not supported although for the lab I deployed a single-node one.

NSX Data Plane

The Data Plane will be implemented by the previously referred transport nodes, this is OVS devices and NSX appliances, managed by the Controller Cluster.

Hypervisors: The compute nodes leveraging Open vSwitch to provide network connectivity for the virtual machines.

NSX Gateway/s: The NSX Gateways formed the Gateway Service that allows a logical network to be attached to a physical network not managed by NSX. The gateways can be L2 Gateway, expands L2 logical segment to include a physical one, and L3 Gateway that maps itself to physical router port.

NSX Service Node/s: The Service Nodes are OVS enabled appliances that provide extra processing capacity by offloading network packet processing from the hypervisor virtual switches. The type of operations managed by the service nodes are for example assisting with the packet replication during broadcast/multicast operations or unknown multicast flooding in overlay logical networks.

NSX Management Plane

The NSX Management Plane is composed exclusively by the NSX Manager. Provides a different and more friendly way to interact with the NVP API, and configure the logical network components for example, through its web UI. In an OpenStack deployment there is need to use it, however it can be helpful for troubleshooting purposes.

NSX network appliances deployment

For our lab purposes create four Ubuntu x64 virtual machines with 1vCPU, 1GB of RAM, 1 network interface (E1000) and 16GB of disk.

NSX Controller

Power on the VM and on the boot screen select Automated Install.

Screen Shot 2014-04-27 at 20.49.15

The installation will take several minutes to finish. When it’s finished you will see a prompt like this in the virtual machine console.

Screen Shot 2014-04-27 at 22.42.11

Login as admin user with password admin. In a normal deployment you will configure admin user password with set admin user password but for the lab is not needed.

Set the IP address for the controller node.

nsx-controller # set network interface breth0 static
Setting IP for interface breth0...
Clearing DNS configuration...
nsx-controller # 
nsx-controller # show network interface breth0
IP config: static
MTU: 1500
MAC: 00:0c:29:92:ce:0c
Admin-Status: UP
Link-Status: UP
SNMP: disabled
nsx-controller #

Configure the hostname.

nsx-controller # set hostname nsxc
nsxc #

Next configure the default route.

nsxc # add network route
nsxc #
nsxc # show network route
Prefix/Mask         Gateway         Metric  MTU     Iface     0       intf    breth0         0       intf    breth0
nsxc #

Set the address of the DNS and NTP servers.

nsxc # add network dns-server
nsxc #
nsxc # add network ntp-server
 * Stopping NTP server ntpd                                                                                                                                                          [ OK ]
Synchronizing with NTP servers. This may take a few seconds...
27 Apr 21:03:49 ntpdate[3755]: step time server offset -7199.735794 sec
 * Starting NTP server ntpd                                                                                                                                                          [ OK ]
nsxc #

Set the management address of the control cluster.

set control-cluster management-address

Configure the IP address to be used for communication with the different transport nodes.

set control-cluster role switch_manager listen-ip

Configure the IP address to handle NVP API requests.

set control-cluster role api_provider listen-ip

Finally join the cluster, since this the first node of the cluster the IP has to be its own one.

nsxc # join control-cluster
Clearing controller state and restarting
Stopping nicira-nvp-controller: [Done]
Clearing nicira-nvp-controller's state: OK
Starting nicira-nvp-controller: CLI revert file already exists
mapping eth0 -> bridged-pif
ssh stop/waiting
ssh start/running, process 5009
mapping breth0 -> eth0
mapping breth0 -> eth0
ssh stop/waiting
ssh start/running, process 5158
Setting core limit to unlimited
Setting file descriptor limit to 100000
 nicira-nvp-controller [OK]
** Watching control-cluster history; ctrl-c to exit **
Host nsx-controller
Node ffac511c-12b3-4dd0-baa7-632df4860521 (
  04/27 22:40:42: Initializing data contact with cluster
  04/27 22:40:49: Fetching initial configuration data
  04/27 22:40:51: Join complete
nsxc #

You can check at any moment the status of the node in the cluster with the show control-cluster status command.

nsxc # show control-cluster status
Type                Status                                       Since
Join status:        Join complete                                04/27 22:40:51
Majority status:    Disconnected from cluster majority           04/27 22:53:44
Restart status:     This controller can be safely restarted      04/27 21:23:29
Cluster ID:         7837a89a-22f3-4c8c-8bef-c100886374e9
Node UUID:          7837a89a-22f3-4c8c-8bef-c100886374e9

Role                Configured status   Active status
api_provider        enabled             activated
persistence_server  enabled             activated
switch_manager      enabled             activated
logical_manager     enabled             activated
directory_server    disabled            disabled
nsxc #

In a standard NSX deployment now would the moment to add more nodes to the cluster using again the join control-cluster command with the same IP address.

NSX Gateway

Proceed with the Automated Install as in the Controller node. When the installation is done login as admin user.

Set IP address.

set network interface breth0 static

Set hostname.

set hostname nsxg

Configure the rest of the network parameters as in the Controller node and proceed to the gateway specific configuration.

nsxg # add switch manager
Waiting for the manager CA certificate to synchronize...
Manager CA certificate synchronized
nsxg #

NSX Service Node

Again launch the Automated Install and let it finish. As admin user configure the IP address…

set network interface breth0 static

…and the hostname.

set hostname nsxsn

Finish the network configuration as in the Gateway and the Controller and configure the Service Node to be aware of the Controller Cluster

add switch manager

The above command will return an error like this.

Manager CA certificate failed to synchronize.  Verify
the manager is running on the specified IP address.

It’s normal since the Transport Node will not be able to connect to the NSX Controller Cluster until the cluster has been informed, either via NVP API or NSX Manager interface, about the existence of the Transport Node.

NSX Manager

Access the NSX Manager console, you have to see a similar screen.

Screen Shot 2014-04-28 at 00.47.54

Set the IP and the hostname and configure the default route, DNS and NTP server.

set network interface breth0 static
set hostname nsxm
add network route
add network dns-server
add network ntp-server

With this we have completed the installation and initial configuration of our four NSX appliances. In a real world deployment we should have to add at least two more NSX controller nodes to our cluster and maybe one or more gateways in order to setup L2 and L3 Gateway Services. The number of Service Nodes will depend on the expected load of our cloud.

Connect the NSX Manager to the Controller Cluster

Our next step is to connect our newly crested NSX Controller Cluster with NSX Manager. Access NSX Manager web interface and login as admin user.

Screen Shot 2014-04-28 at 01.10.19

After the login the Manager will indicate that there is no Controller Cluster added.

Screen Shot 2014-04-28 at 01.15.33

Click the Add Cluster button and enter the data for the NSX Controller Cluster.

Screen Shot 2014-04-28 at 01.26.03

If the connection is successful the a new screen will show up.

Screen Shot 2014-04-28 at 01.36.29

Provide the following information:

  • Name of the cluster
  • Contact email address of the administrator
  • Automatically Use New IPs – This setting, checked by default, will add all the IP address of the members form this cluster as eligible to receive API call from the NSX Manager.
  • Make Active Cluster

In the next screen enter the IP address of your syslog server or click Use This NSX Manager to use the NSX Manager as syslog server.

Screen Shot 2014-04-28 at 01.57.43

After clicking in Configure the Manager will finish the configuration of the Controller Cluster and will go back the previous screen where we can see the new cluster we have just added to the Manager.

Screen Shot 2014-04-28 at 02.01.44

In the next post we will see how to configure NSX Transport and Logical network elements. As always comments are welcome.


In the first post of the series we discussed Chargeback API basics and how to interact with it using Firefox REST Client. In this second and final post we will see how Chargeback integrates with vCenter Orchestrator.

VMware provides a plugin for the integration between vCO and CBM, however there some caveats with that plugin. First it is for version 2.0 and to be able to use it with 2.5 or above there are some changes to perform, the whole process is described in VMware KB 203145.

Second gotcha of the plugin is that it doesn’t cover every possible API within Chargeback, yes you heard it correctly. To cover those parts we need to use the vCO plugin for REST APIs, of course this plugin needs some configuration before being able to interact with Chargeback but will see later how to do it.

Add Chargeback server to vCenter Orchestrator inventory

Open vCenter Orchestrator configuration website at https://vco_server:8283 and install Chargeback and REST plugins. I’m not going to describe the process of installing a plugin since it is fairly well documented in vCO documentation.

Next we need to import Chargeback SSL certificate, go to Network and then to SSL Trust Manager tab. Enter Chargeback server URL in the Import from URL textbox and click Import.


A screen with the details of our Chargeback server will appear, click Import to accept the certificate.


Now from the Chargeback (2.0.0) area go to New Server tab, enter Chargeback server details and click Apply Changes.


In vCO client our new Chargeback server will appear.


Using vCO plugin for Chargeback Integration

vCenter Orchestrator plugin for Chargeback allows to perform several administration tasks in a Chargeback server and also cost management and configuration tasks. Following are several example workflows for both type of actions.

List all hierarchies

We are going to automate a very easy task as our first example. Create a new workflow and name it List Hierarchies. As workflow parameters add:

  • cbmServer – Your Chargeback server. Type Chargeback:ChargebackServer.
  • cbmVersion – Chargeback API version, 2.0. Type string.
  • hierarchyList – The list of hierarchies- Type Array/Chargeback:Hierarchy.

In the Schema tab drag an Action element, a new windows will pop up to choose the action. Search for getAllHiearchies and select it.


Check that the workflows attributes are correctly mapped as the input (cbmServer and cbmVersion) and output (hierarchyList) parameters of the action.

Next add a Scriptable task element to the workflow and edit it. Map hierarchyList attribute as input parameter. In the Scripting tab paste this code.

Validate the workflow and save it. The scheme has to look like this.


In the execution go to the Logs sub-tab in the main Scheme tab to check the results of the execution, if everything went as expected you should see something similar to the screenshot.


You should be thinking that this example is a bit silly, and to be honest it is. There are few use cases that will require to dump the hierarchy list to vCO log. The purpose of this workflow is to illustrate Chargeback plugin Action elements. Open vCO API Explorer and have a look at all the already implemented Actions that can be used in your workflows.


From basic administration tasks to search and reporting. Also Chargeback plugin comes with a set of Scripting Classes and objects that cover all Chargeback objects although as I mentioned before not all available methods are implemented.


Make a call to a method from a scripting class is relatively easy as we will see in the following example. We want to get a hierarchy and later use in a different task. We can use a method from CbServer class: getHierarchyByName. It accepts the hierarchy name and CBM API version as parameters. Basic syntax would be:

The hierarchy scripting object is now instantiated and we can get any property from it, like its ID.

Using vCO HTTP-REST plugin with Chargeback

vCenter Orchestrator has available an HTTP-REST plugin that enables it to interface with systems without a plugin or, like CBM case, to be able to execute some operations not implemented in the plugin. Current vCO plugin doesn’t have implemented the possibility to manage fixed costs in Chargeback. However using the plugin for REST APIs we can circumvent that shortage. But before creating any workflow we need to configure the REST plugin for Chargeback.

Configure REST plugin

vCenter Orchestrator plugin for REST APIs comes with a set of workflows for configuration purposes.


We need to add first our Chargeback server as REST host. Launch the Add a REST host workflow. Enter the name of the REST host and the base URL for the API, leave the timeout settings with the default values.


In the next two steps select Basic authentication mode…


…shared session and enter Chargeback server credentials.


Click submit and have a look at the workflow execution.

If everything went fine we cam see our new REST host in vCO inventory under HTTP-REST. Next step is add the API operations we need to execute using this plugin. Or course you have to add a Login and Logout operation and for our example we are going to add the following ones:

  • Create new Hierarchy
  • Add new Fixed Cost
  • Get Task Status – We will not use this one in any of the workflows of the post but I decided to add it to show how to add URL parameters

Launch Add a REST operation workflow and enter the following parameters:

  • Parent host – Our previously added REST host.
  • Name – a unique name for the operation.
  • Template URL – This the API signature in the case of Chargeback. The URL can contain placeholder for parameters to be provided during request phase of the operation.
  • HTTP Method .
  • Content Type – Optional parameter only for POST and PUT methods. Below are the screenshots and parameters for the five REST operations we need to add.

- Login:



- Logout:


- Create a new hierarchy:


- Add a new Fixed Cost:


- Get task status:


Look at in the inventory in vCenter Orchestrator client and check that all the new added operations appear under Chargeback REST host.


Now we can proceed to create our workflows.

Add a new Hierarchy to Chargeback

We are going to reproduce one the examples from Part 1 using vCO. First create a new empty workflow. As attributes we are going to use the following ones:

  • cbmVersion – Chargeback API version, 2.0.
  • cbmUser – User with administrative privileges in Chargeback
  • cbmPassword – Password of the above user
  • restLogin – Login REST Operation
  • restLogout – Logout REST Operation
  • restCreateHierarchy – Create hierarchy REST Operation
  • loginStatus – Status of the login REST Operation.


Next configure the input parameters, basically for our purposes here we will need the hierarchy name description.


At the presentation layer the parameters will shown as Name of the new hierarchy and Description for the new hierarchy.


Add two Scriptable tasks to the workflow, name the first as API Login and the second as API Logout and paste the code from the previous Login and Logout examples. Now add a third scriptable task to be executed after the login, name it as “Create Hierarchy” and edit it. Paste the below code in the Scripting tab.

Edit the API Login element and in the scripting tab add the following Javascript code.

With this chunk of code will suffice to launch the operation, however there is no error control. The HTTP status code is not enough because the login operation can fail even with a 200 code, like the example below.


To solve this we need to parse the response content. REST plugin scripting API provides a method to retrieve the content of the response as a string.


The following code will do the trick.

Firstly we need to convert the string to and array, then we get the second element of the array since and look for a successful status. The element has loginStatus as output parameter bind to the attribute of the same name. The System.log statements are not required but can be useful for troubleshooting purposes.

Add a Decision element to the workflow and bind the decision to the loginStatus parameter.


Change the failure branch of the decision from End workflow to Throw exception and bind it to loginStatus. With this decision element we can force the workflow to end the execution if the API login operation was unsuccessful.

Next edit the Create hierarchy element. Bind restCreateHierarchy, cbmUser, cbmPassword and cbmVersion attributes as input parameters, also bind hierarchyName and hierarchyDescription as input parameters.


In the scripting tab paste this code.

The last part, this is the REST operation output is optional but again it can be useful if we need to troubleshoot the workflows using vCO logs.

Our workflow is done and it should look like this.


Launch it and enter a name and a description to test it.


Click Submit, check the workflow logs for any errors and if everything went as expected go to Chargeback UI and see that the new hierarchy is there.


Add new Fixed Cost

For our second workflow we are going the same structure as before. hence the first task is duplicate our first workflow and edit the copy. As input parameters we will use:

  • cbmVersion – Chargeback API version, 2.0.
  • cbmUser – User with administrative privileges in Chargeback
  • cbmPassword – Password of the above user
  • restLogin – Login REST Operation
  • restLogout – Logout REST Operation
  • restAddFixed Cost – Add new fixed cost REST Operation
  • loginStatus – Status of the login REST Operation.


Very similar to the hierarchy one. However in this case as input parameters we will need much more information.

  • fixedCostName – Fixed Cost name
  • fixedCostDescription – Fixed Cost Description
  • fixedCostCurrency – ID for the currency. A full list of the currencies supported by Chargeback can be found in the API Reference. US Dollar is 104 and Euro 31.
  • isProrated – Configure the new fixed cost as prorated or not. Default value is true. Cannot be used with one-time fixed costs.
  • isPowerStateBased – Configure the fixed cost to be applied only if the virtual machine is powered on. It’s not mandatory, default value is false.
  • fixedCostType – Fixed cost type. A value of 0 represents a recurring fixed cost and 1 represents a one-time fixed cost. It’s not mandatory and the default value is 0.


Some of the input parameters are optional but we will use all to illustrate the example with all the possible details. At Presentation add a new property for the name and description to make them mandatory. You can also set the default values for the rest of the parameters.


Change the name of the second scriptable task to Add new Fixed Cost and edit it. Bind all the needed parameters and attributes.


In the XML payload we need to reflect all these parameters. Below is code for the scripting part.

Validate the workflow and save it. Execute it and fill in the input parameters.


Check in the Chargeback UI our newly created Fixed Cost.


We can also have a look at the API response in the workflow logs.


And we are done. This is the end of this two-post series and I hope that know you all have a better understanding of Chargeback API. As your next step my advice is to try to automate simple API tasks, even if they don’t seem to be very useful, and then combine thme into  more complex automation workflows along with vCenter and vCloud Director plugins.

In future posts I’ll show a couple of real world examples about how I have used CBM and REST plugins in some customer deployments.


vCenter Chargeback provides a fully featured API that allows to automate many tasks like user and rights management, cost configuration or reporting.

Chargeback API is a REST-based one, this means that it will receive requests and send responses using HTTP protocol and methods. CBM API implements a set of basic CRUD operations, and each of them maps with an HTTP method as shown in he below table.


API syntax is actually very easy, it is composed of:

  • Request method
  • Base URL
  • API signature

It’s better illustrated with an example:

POST https://chargeback.corp.local/vCenter-CB/api/login?version=2.5

We can map the above example with the different elements of the API syntax:

We have also included the API version, I usually includes the version as an URL parameter but as we will see later is not really required. Some of the tasks will need also URL parameters that will be placed after the signature.

If there is need for more complex information either in the request or the response an XML payload have to be sent, just like in many other REST APIs. Even to perform a simple login an XML has to be sent, just like the next example.

For our first ride with CBM API we will use Firefox REST Client add-on, can be found here, this handy add-on provides a visual an easy way to quickly ramp up with any REST API. I personally have used it a lot with Chargeback to try the different API operations during a development project for a customer.

I’m not going to review every possible API, just a few examples to illustrate how it works.

imageLogin operation:

This is the most basic operation of all. In the REST Client paste the XML payload in the Body area, select POST as the method to use and fill the URL field.


Get hierarchy list:

Not every task needs an XML payload, in the following example we are going to get a list of the hierarchies using a GET method and with no message body. The URL to make the request would be:


After executing the request we can see in the REST Client the response from Chargeback in XML format.


If we go to Chargeback web UI we’ll see the listed hierarchies.


Get all Pricing Models:

Another simple request with no XML payload, with a similar syntax to the previous one:

GET https://<chargeback_server>/vCenter-CB/api/costModels?version=2.5

It will produce however a much more detailed response XML with the details of each of the configured Pricing Models.

<?xml version="1.0" encoding="UTF-8"?>
<Response xmlns="http://www.vmware.com/vcenter/chargeback/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" status="success" isValidLicense="true">
    <CostModel id="31">
      <Name>Default Allocation Based Chargeback Pricing Model</Name>
      <Description>(DONT DELETE) This is only for optimization reports, only base rates are allowed for editing.</Description>
      <Currency id="104">
    <CostModel id="30">
      <Name>Default Chargeback Pricing Model</Name>
      <Description>This is the default pricing model shipped with VMware vCenter Chargeback Manager.</Description>
      <Currency id="104">
    <CostModel id="558">
      <Name>VMware Cloud Director Actual Usage Pricing Model</Name>
      <Description>Apply this pricing model to charge for actual usage in hierarchy</Description>
      <Currency id="104">
    <CostModel id="548">
      <Name>VMware Cloud Director Allocation Pool Pricing Model</Name>
      <Description>Apply this pricing model on vDC with Allocation model as 'Allocation Pool' in hierarchy</Description>
      <Currency id="104">
    <CostModel id="550">
      <Name>VMware Cloud Director Networks Pricing Model</Name>
      <Description>Apply this pricing model on organization networks in hierarchy</Description>
      <Currency id="104">
    <CostModel id="556">
      <Name>VMware Cloud Director Overage Allocation Pool Pricing Model</Name>
      <Description>Apply this pricing model to charge for overage on vDC with Allocation model as 'Allocation Pool' in hierarchy</Description>
      <Currency id="104">
    <CostModel id="554">
      <Name>VMware Cloud Director Pay As You Go - Fixed Charging Pricing Model</Name>
      <Description>Apply this pricing model for 'Fixed charging' on vDC with Allocation model as 'Pay As You Go' in hierarchy</Description>
      <Currency id="104">
    <CostModel id="552">
      <Name>VMware Cloud Director Pay As You Go - Resource Based Charging Pricing Model</Name>
      <Description>Apply this pricing model for 'Resource based charging' on vDC with Allocation model as 'Pay As You Go' in hierarchy</Description>
      <Currency id="104">
    <CostModel id="546">
      <Name>VMware Cloud Director Reservation Pool Pricing Model</Name>
      <Description>Apply this pricing model on vDC with Allocation model as 'Reservation Pool' in hierarchy</Description>
      <Currency id="104">

Add a new hierarchy:

invoked using a POST method, that corresponds with the CREATE operation from the table at the beginning of the post. The syntax for the request would be:

POST https://<chargeback_server>/vCenter-CB/api/hierarchy

In this case I’m not going to put the version as a parameter. An XML payload with the details of the new hierarchy is required.


Login to Chargeback web interface to check that the new hierarchy is there.


I hope that now you have at least a general understanding of how Chargeback API works and how easy is to interact with it. In the second post of the series we will review how to automate Chargeback using vCenter Orchestrator.


VMware has released VMware vSphere Mobile Watchlist. It is available for Android and iOS, iPhone only for now, and will enable any system administrator to keep an eye on their most critical apps from their phones.

It is a very intuitive app to use, below are a series of screenshots from the app installed on my iPhone 5 and connected to my homelab vCenter Server.

From the main screen you can add virtual machines from your vCenter inventory to the default watchlist or create a new watchlist.

Once you have added several virtual machines to your list you can check them in a glance in list or grid mode.

VM watchlist

Tap on a VM and you will access its details, configured resources, VM Tools state, related objects, etc.

As you can see from the screenshot this a multi screen so slide to the left and you can get a console screenshot of the virtual machine and perform different actions on the virtual machine.

Console screenshot    

I hope this is a step towards a new set of mobile apps from VMware focused on the administration of the different components of a virtual and cloud infrastructure :)


Every customer usually asks about how to monitor their vCenter Chargeback installations, hence I finally decided to write a small post listing the services and processes of the different Chargeback components.

Windows Service Path to executable
VMware vCenter Chargeback C:\Program Files (x86)\VMware\VMware vCenter Chargeback\apache-tomcat\bin\tomcat6.exe
VMware vCenter Chargeback – VMware Cloud Director DataCollector C:\Program Files (x86)\VMware\VMware vCenter Chargeback\VMware Cloud Director DataCollector\JavaService.exe
VMware vCenter Chargeback – vShield Manager DataCollector C:\Program Files (x86)\VMware\VMware vCenter Chargeback\vShield Manager DataCollector\JavaService.exe
VMware vCenter Chargeback DataCollector-Embedded C:\Program Files (x86)\VMware\VMware vCenter Chargeback\DataCollector-Embedded\JavaService.exe
VMware vCenter Chargeback Load Balancer C:\Program Files (x86)\VMware\VMware vCenter Chargeback\Apache2.2\bin\httpd.exe

Bear in mind that if vShield and vCloud DataCollectors are installed on the same server as Chargeback Server the path will be slightly different:

VMware vCenter Chargeback – vShield Manager DataCollector-Embedded C:\Program Files (x86)\VMware\VMware vCenter Chargeback\vShield Manager DataCollector-Embedded\JavaService.exe
VMware vCenter Chargeback DataCollector-Embedded C:\Program Files (x86)\VMware\VMware vCenter Chargeback\DataCollector-Embedded\JavaService.exe


Today VMware has released the latest release of vCenter Chargeback Manager. Although this release is more an update than a completely new one that doesn’t mean it comes without new features, on the contrary. The full list of new features and more information about 2.6 release of Chargeback can be found on its Release Notes. Some of the most interesting are:

  • Compatibility with 5.5 versions of vSphere and vCloud Director
  • Windows Server 2012 Standard support as host operating system
  • Microsoft SQL Server 2012 s supported database

However amongst every other new feature the one that has immediately captured my attention is that finally the vCenter Server Appliance vPostgres embedded database is supported. For me it is a very welcomed new addition, combining CBM 2.6 with vCSA 5.5 you can now manage the cost of your vSphere environment without the need of having an external Oracle database or a Windows-based vCenter Server.

In the Add a New vCenter Server dialog you will notice that Postgres now appears as an option.


For this option there no need to configure database user, instance or port; just provide vCSA IP/FQDN, root user password and we are done.


When the process is completed the newly configured vCenter Server and its database can be checked as always in the settings tab.



I found this error last week during a deployment in a customer. The vCenter Infrastructure Navigator appliance does not maintain its configured hostname after a reboot, it gets reset to the default localhost.localdom value.


Setting it again in the administration web interface doesn’t solve problem, it will be lost again after the next reboot.

The problem is in the vami_set_hostname script, it has a HOSTNAME variable set to localhost.localdom and if it fails to make the reverse lookup of the hostname from the IP address using the host command it will be set to the default value.


To fix this edit that file, it can be found on /opt/vmware/share/vami, and set the value of the variable to your hostname. After that reboot the appliance to check that everything works as expected.


I thought it would be worthy to write a quick post to show the script I’ve been using to create CBM databases in customers installations. The original script wasn’t mine, honestly I don’t know who wrote it, and I’ve modified it to suit my needs.

Just remember to adjust the path of the files, its size, the usernames and password to your environment standards. Hope you find it helpful.


After the previous article about SSL certificate generation in Chargeback I decided that it was worth to write a couple more tips in a second blog post. This is not a “how to install…” or “how to configure…” post. There are other bloggers in the community that have written about it before so I believe there is no point on repeating the same.

Database configuration

At one point the CBM installer will ask for the database details, apparently nothing to worry about. Except for the following:

  • Port: It says is optional but if you don’t enter the port the connection will fail. The default port is 1433 but of course fill it with the value from your installation.


Adding a vCenter Server

The first task you want to perform after Chargeback installation is to add a vCenter Server, in theory pretty easy until you get to the database screen. It is very important to remember that in the Database URL field you only need to put the database server IP address as shown in the screen capture.



This year edition of VMworld Europe 2013 is gone. For second time it was held in Barcelona, one of most beautiful cities of Spain, and for the second time I was there to enjoy a great week… and what a week.

If you weren’t under a rock during last week you are probably aware of the announcements in the cloud management space, with new upcoming releases for vC Ops, ITBM and vCAC just to name some. Or the announcement of VMware NSX going GA and the tech preview of vSAN.

Regarding the announced vCAC 6.0 the attendees had a glimpse of its awesomeness in the Hands-on Labs since the HOL-SDC-1321 lab was based on 6.0 Beta bits. vCAC 6.0 was also featured in a very well executed keynote by Kit Colbert and our EMEA CTO Joe Baguley on Wednesday morning, showing from all the new features in the portal to the integration with VMware vCHS and other public cloud providers.

I am genuinely excited about this new vCloud Automation Center release and will come back with more articles about my experience with it in the future. In the meantime my friend and colleague Omer has done a nice article in his blog Elastic Skies about what’s new.

But that’s only one side of the coin, for me the most important aspect of VMworld is the Community. This is the only time of the year I have the opportunity to hang face to face with many of the people I already consider my friends, this is I’m not sales, marketing or social media, I am a consultant as you all know and that means that I’m always in the field doing engagements for customers and having lots of fun of course but that leave me no time or even the chance to attend tech conferences… besides VMworld :-)

And this year has been AWESOME!

I had again the opportunity of attending several parties. Parties are always sponsored by several companies, like Cisco, EMC or Simplivity, but in some of them the sense of community is omnipresent.

Take the vRockstar Party for example, held on Sunday evening at the Hard Rock Cafe. That really was a community event, the perfect moment to share a few beers (more than a few actually ;D) a good conversations and strength your friendship with the other members of the community. Or the GeekFest on Tuesday night, again at the Hard Rock and sponsored by EMC, Cisco and VMware. Oh man that party was really great with amazing food and beer and many many friends from all around the world there.

But for me the best example this year was the #BeerTweetup organized by Hans De Leenheer (@HansDeLeenheer) and sponsored by Simplivity. IMHO that was a true community event, no marketing, no vendor swag, just good Belgium beer, great talking and good company.

But hey it wasn’t all about the parties, at least no during the night you know, seriously parties are amazing but it was the only part of the fun. During all day, for three days, some of the most active and prominent members of the VMware community were spreading the word in the Community Lounge. I’m taking about the guys of #vBrownbag or James Bowling (@vsential) and his Operation: Through my eyes series of videos or Craig Waters (@cswaters1) who interviewed many other vExperts for his blog.

Also for me this VMworld has been very special since I had the opportunity to contribute to the community besides of this blog, and of my awesome drinking skills of course ;D My friend Amy Lewis (@CommsNinja) finally manage to got me into her video podcast Engineers Unplugged, Amy and his team really know how to bring social media and community to a different level. As my “opponent” I had Matthew Yeager himself (@mpyeager) from EMC and we had tons of fun recording it and talking about cloud management, APIs and the Software Defined Datacenter. As soon as Amy gets the video up in the show YouTube channel I will feature it here.

My final though is if next year you have the opportunity of going to VMworld, either US or Europe, take it and show up in the community lounge to have some good conversations with the great people there, show your support to that people, get into the parties and enjoy the conference. You won’t regret it, surely I didn’t :-)