Archives For Virtualization

kvmWelcome to the third post of my series about OpenStack. In the first and second posts we saw in detail how to prepare the basic network infrastructure of our future OpenStack cloud using VMware NSX. In this third one we are going to install and configure the KVM compute host and the shared storage of the lab.

KVM setup

Create and install two CentOS 6.4 virtual machines with 2 vCPU, 2 GB of RAM, 2 network interfaces (E1000) and one 16GB disk. For the partitioning schema I have used the following one:

  • sda1 – 512MB – /boot
  • sda2 – Rest of the disk – LVM PV
    • lv_root – 13.5GB – /
    • lv_swap – 2GB – swap

Mark Base and Standard groups to be installed and leave the rest unchecked. Set the hostname during the installation and leave the networking configuration with the default values. Please have in mind that you will need to have a DHCP server on your network, in my case I’m using the one that comes with VMware Fusion if you don’t have one then you will have to set here a temporary IP address in order to able to install the KVM software. Once the installation is done reboot your virtual machine and open a root SSH session to proceed with the rest of the configuration tasks.

Disable SELinux with setenfornce command, also modify SELinux config to disable it during OS boot. I do not recommend to disable SELinux in a production environment but for a lab it will simplify things.

setenforce 0
cp /etc/selinux/config /etc/selinux/config.orig
sed -i s/SELINUX\=enforcing/SELINUX\=disabled/ /etc/selinux/config

Check that hardware virtualization support is activated.

egrep -i 'vmx|svm' /proc/cpuinfo

Install KVM packages.

yum install kvm libvirt python-virtinst qemu-kvm

After installing a ton of dependencies and if t nothing failed enable and start the libvirtd service.

[root@kvm1 ~]# chkconfig libvirtd on
[root@kvm1 ~]# service libvirtd start
Starting libvirtd daemon:                                  [  OK  ]
[root@kvm1 ~]#

Verify that KVM has been correctly installed and it’s loaded and running on the system.

[root@kvm1 ~]# lsmod | grep kvm
kvm_intel              53484  0
kvm                   316506  1 kvm_intel
[root@kvm1 ~]#
[root@kvm1 ~]# virsh -c qemu:///system list
 Id    Name                           State

[root@kvm1 ~]#

Hypervisor networking setup

With KVM software installed and ready we can now move on to configure the networking for both hosts and integrate them into our NSX deployment.

Disable Network Manager for both interfaces. Edit /etc/sysconfig/network-scripts/ifcfg-ethX files and change NM_CONTROLLED value to no.

By default libvirt creates virbr0 network bridge to be used for the virtual machines to access the external network through a NAT connection. We need to disable it to ensure that bridge components of Open vSwitch can load without any errors.

virsh net-destroy default
virsh net-autostart --disable default

Install Open vSwitch

Copy the NSX OVS package to the KVM host and extract it.

[root@kvm1 nsx-ovs]# tar vxfz nsx-ovs-2.1.0-build33849-rhel64_x86_64.tar.gz
[root@kvm1 nsx-ovs]#

Install Open vSwitch packages.

rpm -Uvh kmod-openvswitch-
rpm -Uvh openvswitch-

Verify that Open vSwitch service is enabled and start it.

[root@kvm1 ~]# chkconfig --list openvswitch
openvswitch     0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@kvm1 ~]#
[root@kvm1 ~]#
[root@kvm1 ~]# service openvswitch start
/etc/openvswitch/conf.db does not exist ... (warning).
Creating empty database /etc/openvswitch/conf.db           [  OK  ]
Starting ovsdb-server                                      [  OK  ]
Configuring Open vSwitch system IDs                        [  OK  ]
Inserting openvswitch module                               [  OK  ]
Starting ovs-vswitchd                                      [  OK  ]
Enabling remote OVSDB managers                             [  OK  ]
[root@kvm1 ~]#

Install nicira-ovs-hypervisor-node package, this utility provides the infrastructure for distributed routing on the hypervisor. With the installation the integration bridge br-int and OVS SSL credentials will be created.

[root@kvm1 ~]# rpm -Uvh nicira-ovs-hypervisor-node*.rpm
Preparing...                ########################################### [100%]
   1:nicira-ovs-hypervisor-n########################################### [ 50%]
   2:nicira-ovs-hypervisor-n########################################### [100%]
Running '/usr/sbin/ovs-integrate init'
successfully generated self-signed certificates..
successfully created the integration bridge..
[root@kvm1 ~]#

There are other packages like nicira-flow-stats-exporter and tcpdump-ovs but they are not needed for OVS functioning. We can proceed now with OVS configuration.

Configure Open vSwitch

The first step is to create OVS bridges for each network interface card of the hypervisor.

ovs-vsctl add-br br0
ovs-vsctl br-set-external-id br0 bridge-id br0
ovs-vsctl set Bridge br0 fail-mode=standalone
ovs-vsctl add-port br0 eth0

If you were logged in by an SSH session you have probably noticed that your connection is lost, this is because br0 interface has taken control of the networking of the host and it doesn’t have an IP address configured. To solve this access the host console and edit ifcfg-eth0 file and modify to look like this.


Next create and edit ifcfg-br0 file.


Restart the network service and test the connection.

service network restart

Repeat all the above steps for the second network interface.

Finally configure NSX Controller Cluster as manager in Open vSwitch.

ovs-vsctl set-manager ssl:

Execute ovs-vsctl show command to review OVS current configuration.

[root@kvm1 ~]# ovs-vsctl show
    Manager "ssl:"
    Bridge "br1"
        fail_mode: standalone
        Port "br1"
            Interface "br1"
                type: internal
        Port "eth1"
            Interface "eth1"
    Bridge "br0"
        fail_mode: standalone
        Port "eth0"
            Interface "eth0"
        Port "br0"
            Interface "br0"
                type: internal
    Bridge br-int
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
    ovs_version: ""
[root@kvm1 ~]#

Register OVS in NSX Controller

With our OVS instance installed and running we can now inform NSX Controller of its existence either via NVP API or NSX Manager, in our case we will use the later.

Log into NSX Manager as admin user and go to Dashboard, from Summary of Transport Components table click Add in the Hypervisors row. Verify that Hypervisor is selected as transport node and move to the Basics screen. Enter a name for the hypervisor, usually the hostname of the server.

Screen Shot 2014-05-05 at 23.18.22

In Properties enter:

  • Integration bridge ID, for us is br-int.
  • Admin Status Enabled -  Enabled by default.

Screen Shot 2014-05-05 at 23.29.03

For the Credential screen we are going to need the SSL certificate that was created along with the integration bridge during the NSX OVS installation. The PEM certificate file is ovsclient-cert.pem and is in /etc/openvswitch directory.

[root@kvm1 ~]# cat /etc/openvswitch/ovsclient-cert.pem
[root@kvm1 ~]#

Copy the contents of the file and paste them in the Security Certificate text box.

Screen Shot 2014-05-05 at 23.36.28

Finally add the Transport Connector with the values:

  • Transport Type: STT
  • Transport Zone UUID: The transport zone, in my case the UUID corresponding to vlab-transport-zone.
  • IP Address – The address of the br0 interface of the host.

Screen Shot 2014-05-05 at 23.41.57

Click Save & View and check that Management and OpenFlow connections are up.

Screen Shot 2014-05-05 at 23.52.16

GlusterFS setup

gluster-logo-300x115I choose GlusterFS for my OpenStack lab for two reasons.  I have used it in the past so this has been a good opportunity for me to refresh and enhance my rusty gluster skills, and it’s supported as storage backend for Glance in OpenStack. Instead of going with CentOS again this time I choose Fedora 20 for my gluster VM, a real world GlusterFS cluster will have at least two node but for our lab one will be enough.

Create a Fedora x64 virtual machine with 1 vCPU, 1GB of RAM and one network interface. For the storage part use the following:

  • System disk: 16GB
  • Data disk: 72GB

Use the same partitioning schema of the KVM hosts for the system disk. Choose a Minimal installation and add the Standard group. Configure the hostname and the IP address of the node, set the root password and create a user as administrator, I’m using here my personal user jrey.

Disable SELinux.

sudo setenforce 0
sudo cp /etc/selinux/config /etc/selinux/config.orig
sudo sed -i s/SELINUX\=enforcing/SELINUX\=disabled/ /etc/selinux/config

Stop and disable firewalld.

sudo systemctl disable firewalld.service
sudo systemctl stop firewalld.service

Install GlusterFS packages. There is no need to add any additional yum repository since Gluster is included in the standard Fedora repos.

sudo systemctl install glusterfs-server

Enable Gluster services.

sudo systemctl enable glusterd.service
sudo systemctl enable glusterfsd.service

Start Gluster services.

[jrey@gluster ~]$ sudo systemctl start glusterd.service
[jrey@gluster ~]$ sudo systemctl start glusterfsd.service
[jrey@gluster ~]$
[jrey@gluster ~]$ sudo systemctl status glusterd.service
glusterd.service - GlusterFS an clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled)
   Active: active (running) since Mon 2014-04-28 17:17:35 CEST; 20s ago
  Process: 1496 ExecStart=/usr/sbin/glusterd -p /run/ (code=exited, status=0/SUCCESS)
 Main PID: 1497 (glusterd)
   CGroup: /system.slice/glusterd.service
           └─1497 /usr/sbin/glusterd -p /run/

Apr 28 17:17:35 gluster.vlab.local systemd[1]: Started GlusterFS an clustered file-system server.
[jrey@gluster ~]$
[jrey@gluster ~]$ sudo systemctl status glusterfsd.service
glusterfsd.service - GlusterFS brick processes (stopping only)
   Loaded: loaded (/usr/lib/systemd/system/glusterfsd.service; enabled)
   Active: active (exited) since Mon 2014-04-28 17:17:45 CEST; 15s ago
  Process: 1515 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 1515 (code=exited, status=0/SUCCESS)

Apr 28 17:17:45 gluster.vlab.local systemd[1]: Starting GlusterFS brick processes (stopping only)...
Apr 28 17:17:45 gluster.vlab.local systemd[1]: Started GlusterFS brick processes (stopping only).
[jrey@gluster ~]$

Since we are running a one-node cluster there is no need to add any node to the trusted pool. In case you decide to run a multinode environment you can setup the pool by running the following command on each node of the clsuter. .

gluster peer probe <IP_ADDRESS_OF_OTHER_NODE>

Edit the data disk with fdisk and create a single partition. Format the partition as XFS.

[jrey@gluster ~]$ sudo mkfs.xfs -i size=512 /dev/sdb1
meta-data=/dev/sdb1              isize=512    agcount=4, agsize=4718528 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=18874112, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=9215, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[jrey@gluster ~]$

Create the mount point for the new filesystem, mount the partition and edit /etc/fstab accordingly to make it persistent to reboots.

sudo mkdir -p /data/glance/
sudo mount /dev/sdb1 /data/glance
sudo mkdir -p /data/glance/brick1
sudo echo "/dev/sdb1 /data/glance xfs defaults 0 0" >> /etc/fstab

Create the Gluster volume and start it.

[jrey@gluster ~]$ sudo gluster volume create gv0 gluster.vlab.local:/data/glance/brick1
volume create: gv0: success: please start the volume to access data
[jrey@gluster ~]$
[jrey@gluster ~]$ sudo gluster volume start gv0
volume start: gv0: success
[jrey@gluster ~]$
[jrey@gluster ~]$ sudo gluster volume info

Volume Name: gv0
Type: Distribute
Volume ID: d1ad2d00-6210-4856-a5eb-26ddcba77a70
Status: Started
Number of Bricks: 1
Transport-type: tcp
Brick1: gluster.vlab.local:/data/glance/brick1
[jrey@gluster ~]$

The configuration of the Gluster node is finished. In the next article we will install and configure OpenStack using the different components detailed during current and previous parts of the series.

Please feel free to add any comment or correction.


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="" xmlns:xsi="" 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.



vCenter Chargeback Manager gives you the possibility during the installation process to generate an SSL certificate. But this certificate is generated with an expiration period of 60 days.

No problem with that, you can always regenerate it again. Actually Chargeback provides the mechanism to do it. The process can be launched from the vCenter Chargeback Manager Tools folder as it can be seen in the screenshot below.


However this new certificate will come with the same limitation of 60 days of valid period. To easily avoid that we only need to edit the .bat file that generates the certificate and modify the correspondent value.

The script is called Generate_Ssl_Certificate.bat and can be found C:\Program Files(x86)\VMware\VMware vCenter Chargeback\Apache2.2\bin.


Edit the file using your favorite text editor, in my case I’m using Notepad++, and go to line number 72 as in the capture.


Change the –days flag from 60 to your desired value, in the example the value is 365 this is the certificate will expire in one year.

After we can launch the generation process. The batch file will open a cmd window, stop the CBM Load Balancer service and asks for the passphrase of default.key. You’ll have to enter it three times and after that the process will ask for information about the State, City, common name (usually the server FQDN), company name, email, etc.


After that it will generate the new certificate and will start Load Balancer services.