vCloud is an initiative led by VMware and counts with the collaboration of more than 100 partner including BT, Rackspace, SAVVIS, Sungard, T-Systems and Verizon Business. The main aim of vCloud is to provide a complete solution to deliver enterprise cloud services based on VMware technologies. The vCloud API will allow application providers to deploy their application among a cloud service provided by one of the vCloud partners.
The vCloud API is based on the principles of Representational State Transfer (REST).
The vCloud resource model includes next entities: the Organization that owns the applications, the Virtual Data Centre where different Resource Entities (Virtual Applications Templates, Media devices, and the Virtual Application) and Networks are instantiated. A Virtual Application is an aggregation of one or more Virtual Machines.
There are number of operations to query existing resources or summary of the Organiztation’s resources (GET <entity-uri>) and to delete an specific resource from a Virtual Application (DELETE <vapp-entity-uri>).
There is a Catalog where users can register, get a summary, down/upload or delete a catalog item (vApp templates, media files such as ISO images, etc.).
vCloud application lifecycle model defines a number of steps where a number of operations can be performed:
- Provisioning: creation of clonning of VApps, instantiation of the vApp templates, upload or facilitate the location of vApp parts and instantiation of VApps defined in an OVF package.
- Configuration: a client can reconfigure vApps by adding, removing or modifying OVF sections.
- Deployment: Reservation of all the resources requested by the vApp (POST <vapp-uri>/action/deploy)
- State Operations: once the resources are reserved the vApp have to be started by powering on all the resources (POST <vapp-uri>/power/action/powerOn), and later on it can be powered off, reset, suspended, shutdown, rebooted, etc.
As some of the previous operations can take time,pending task can be retireved (GET <task-list-uri>/<task-uri>) and cancelled (POST <task-uri>/action/cancel).
There are some other administrative operations to manage Organizations, Virtual Data Centres, users, etc.
As conclusion, we see that the basic service lifecycle management is very well covered, but advanced features (dynamic scalability, SLA management, monitoring or usage accounting) that has been researched in projects as RESERVOIR are not included but it would not be difficult to extend this API to support them: the RESERVOIR’s OVF extensions could be adopted and some other operations or reporting data should be extended.

