Wellness OCCI

Wellness runs on the following VMware based infrastructure:

  • ESXi server v5.1: Servers operating system.
  • vCenter v5.1: System management. Provides a centralized layer for the servers below.
  • vCloud Suite v1.5: Provides the API base for controlling the system.

An OCCI implementation for VMware technology has been developed in order to expose Wellness Telecom’s resources to the Enactor. As a result, an OCCI parser that transforms current BonFIRE OCCI requests into VMware ones has been developed. The OCCI parser is a web based application that has been designed and implemented in Python language, allowing to be executed on a server witch has a WSGI (Web Server Gateway Interface) module installed on.


These are the the modules that have been used in the application:

  • Python (v2.7): Application Core.
  • Web.py (v0.37): Python Framework that allows handling and interpreting URL requests.
  • ipdb (v0.7): Includes a series of functions for debugging.
  • iphyton (v0.13): Provides a Python Shell to interact with the system.
  • Resquets.py (v0.14): Module that allows sending HTTP request to interact with VMware’s proprietary API .

As productive environment, we have selected an Apache Web Server (version 2.2.22) with the WSGI module enabled to hold the application. The appropriate certificate has been setup to only accept petitions from the BonFIRE architecture and allowing the Enactor to establishing a communication with the Testbed.

Testbed architecture

The testbed architecture is built upon a set of servers organized in layers that allow interacting and controlling the system.


The OCCI Parser provides an interface to interact with the Enactor. It is a REST (Representational State Transfer) application developed by Wellness Telecom that serves as an adapter for the OCCI API used in BonFIRE and the proprietary API that uses vCloud Director. The requests from the Enactor are listened by this application and are translated to a series of sentences for the VMware environment.

vCloud Director provides the proprietary API for interacting with the VMware infrastructure. It also provides a second web base interface to interact with the resources of the system. This application requires a vCenter layer.

vCenter is the management server that controls the physical servers of the infrastructure. It provides an unified interface for the VMware servers within its control. It also determines where the resources are allocated by examining the servers’ workload periodically.

VMware ESXi is the operating system installed on the physical servers. Even though these physical servers have its own management interface, they are not able to interact between them so they delegate that role to the vCenter server

Except for the OCCI Parser that have been designed and developed for this project, the rest of the architecture belongs to a traditional vCloud System.

VMware’s workflow

VMware’s way of work is quite different from BonFIRE’s approach. The following section details how the OCCI parser handles a request made from the Enactor. As an example the creation of a new compute on Wellness is described.

When the OCCI Parser receives the Enactor’s request, it checks whether the user and group contained in the header are registered in to the system. vCloud Director cannot provides support for groups, only for users. To provide a solution and being able to share the resources within a group, the system only works on behalf of the group. If the group is not registered in the system, the application will register it on the fly.

The next step it is to check if the request is properly built by checking the parameters of the compute. If they are not correct, the OCCI Parser will respond the request with a “400 Bad request”.

The BonFIRE approach where the disks containing the operating system can be attached to a compute doesn?t work on the vCloud architecture. These disks are attached to virtual templates and the OCCI Parser will handle it. Furthermore, the virtual machines managed by vCloud Director are deployed in a set of packages called vApps. These ones have an unique identifier that will be used to interact with the virtual machines. A limitation of this approach is that the application is not able to provide an identifier for the system disk, therefore, it will return an “Unknown” tag instead of the disk URL value.

As said before, the virtual machines are deployed from templates that have a standard setup of CPU, RAM memory and disk space. The OCCI Parser needs to change these parameters in order to match the requirements requested. This task takes more time than a standard HTTP request. To avoid a timeout, the application builds an answer with PENDING stated and sends it to the Enactor. At the same time, the application creates a child process that will change the parameters of the virtual machine. It is important to point out that this child process is not able to attend any requests; hence if a problem appears during the creation of the virtual machine the OCCI parser will not be able to inform the Enactor until the next GET request to the testbed.

The following figures shows the application flow for the create compute request:


Features provided by Wellness OCCI

The next section describes the features achieved and not achieved by the OCCI parser in terms of Computes, Networks and Storages


  • Get list of computes

  • Share compute: vCloud Director only works with users, therefore the system is not able to differ between users and groups. To resolve this limitation, the OCCI parser creates users with the name of the group, so when a compute is shared between members of the same group the system provides it as owners of the compute.

  • Get a specific compute: When the disks attached to the virtual machine are listed the one containing the operating system has an “Unknown” value as URL. This disk cannot be detached from the compute and shared with another one.

  • Create new compute: As it was explained before this chapter, the virtual machines are deployed inside of a virtual packet called vApp. The virtual machines are deployed from a template that has to be adapted to the instance type requested. This process takes more time than an standard HTTP request. To fix this the system returns the appropriated answer with a “Pending” state value and starts deploying and configuring the virtual machine on a separated thread.

  • Power off: The Power Off request of the vCloud API leaves the compute in a state of “partially power off”. To fully power off the compute vCloud requires two requests. The first one shutdowns the compute and the second one turns off the vApp leaving the virtual machine in a “not deployed” state.

  • Shutdown: In this case, the machine will remain in a “partially power off” state.

  • Suspend

  • Reboot

  • Delete compute: As occurs with the task of creating a compute, this request takes more time than a HTTP request. To solve this limitation, the system starts a parallel process (thread) to perform this over workload.

  • Update parameters from a compute: The parameters that the system is able to change in a compute are the followings:

    • Name
    • Description
    • Instance type
    • Attach new disk
  • Contextualization

  • Save as: The owner of the virtual machine will be the same that made the request. Furthermore, the copy of the virtual machine or template will affect in the limit of virtual machines of the system.


  • Achieved features

    • Retrieve a list of storages (OS): vCloud cannot disaggregate a virtual machine from the disk that holds the operating system. In this case, the system returns the list of templates available on the infrastructure.
    • Retrieve a list of storages (Datablock)
    • Retrieve a specific storage: The script is not able to show the File System type on the answer. The disk is attached on the template and after it is deployed, there is no place to save this parameter.
    • Delete storage
    • Update storage parameters (Datablock): Independent disks are a recent addition to the vCloud API and there are not many options work with. At this point, the script is only able to update the disk name and its description.
  • Non-Achieved features

    • Update storage parameters (OS): These types of disk are attached to a virtual machine and cannot be disaggregate. This means that the only way to update them is by updating the entire virtual machine.
    • Share storage (OS): The system storage is associated to a template and it is impossible to extract it. Furthermore, it doesn’t have an URL and the only way to contact it is by throwing the virtual machine. This is a limitation of vCloud Director.


vCloud API does not provide functions to modify a network defined on the system. These resources must be defined on a lower level of the architecture (lower than vCloud Director). Hence the only achieved features are listing networks ang getting a specific one.

Differences with other testbeds

  • Private subnets are not possible at WT.
  • WT does not support DATABLOCKS. Therefore only OS disks can be used as storage. In this way, the maximum storage possible on VMs is 10GB and on maximum storage possible on Aggregators is 6GB
  • Aggregator data at WT are lost at the end of an experiment. Hence, the user must perform a SAVE_AS command during the experiment lifetime in order to keep data.
  • Because of VMware limitations, the customization scripts of the virtual machines created at Wellness Telecom have a fixed size. Therefore, the number of SSH public keys that can be transfered to a VM is limited to 70 keys. This number includes all the public keys stored in user?s profiles belonging to the group of the virtual machine.
  • When an user performs a “Save As” command at WT over a VM (Name: “MACHINE_1” / Group: “GROUP_1”) and shares it with the group “GROUP_2”, the resultant VM will belong to both groups (“GROUP_1” and “GROUP_2”). This behaviour is different from other testbeds where the resultant VM would only belong to “GROUP_2”.
  • When a VM is deployed at WT it shows the STOPPED state until it gets running.
  • Usually when an user creates a compute and performs a “SAVE_AS” command this is shown in the OCCI XML of the compute after a GET. However, Wellness is only able to reply with the “SAVE_AS” tag after the “PUT /compute” request. After that, this information is not shown anymore in the GET requests.

Application Flow

When a request is made from the Enactor the OCCI Parser checks the URL and matches it with the appropriate class using the “web.py” library included in the application. Then, the application parses the XML request and builds a Data Model Representation of it. The next step is to make the vCloud request.

There are two types of answers in vCloud, the first one is a direct response of the request, and in this case, the application will parse the response and will build the OCCI answer. The second type is a “Still working” answer. It means that the request needs more time than a standard HTTP request. To avoid this, the application will fork a child process to wait the estimated time between vCloud API requests. After that, it will build an OCCI answer with the data inside the response and the one of the request. This process will be blind and the application will not know if something is wrong until another request from BonFIRE to the same object.


Resources States

Wellness only supports compute resources with the following states:

  • suspended
  • shutdown
  • reboot
  • resume


The Wellness OCCI parser does not read from the MMQ, it only send the following internal site events:

  • Creating a compute (still in pending state): es-wellness.compute.state.pending
  • The compute switchs to running state: es-wellness.compute.state.active.running
  • Changing the state of a compute by a PUT request: es-wellness.compute.state.reserved
  • Deleting a compute: es-wellness.compute.compute.delete
  • Updating a compute: es-wellness.compute.update
  • Deleting a storage: es-wellness.compute.storage.delete