OVF for clouds: one step further

In the general context of cloud interoperability (to decouple the application the cloud user wants to deploy from the cloud infrastructure to which that deployment is issued), OVF has been suggested several times as a very promising candidate. Using this standard (produced by the DMTF), virtual machine based services can be packaged in a vendor a platform neutral way, which makes it very suitable for IaaS clouds.

This “statements of interest” include the Citrix partnership with rPath to “extend Kensho [the flagship OVF-related public Citrix project] to support the deployment of OVF appliances in infrastructure clouds, starting with Amazon EC2”, the Oracle and Intel collaboration to “extend standards that enable portability of virtual machines images such as Open Virtual Format (OVF) and also create Web services standards for provisioning and management of cloud-based services” and the VMware’s vCloud initiative that “will build upon that work [OVF] by submitting a draft of its VMware vCloud API to enable consistent mobility, provisioning, management, and service assurance of applications running in internal and external clouds”.

Although support from the main industrial players is undoubtedly important, these statements basically are no more than declaration of intentions (with the possible exception of vCloud API, but which is too obscure yet to have a precise idea about it). They don’t go further analysing the (not trivial) problems of OVF applied to cloud infrastructure. It is worth mentioning that OVF was not designed with cloud computing in mind, so there are issues that need to be solved when applied to this environment, in particular, on automatic elasticity (OVF is designed for static deployments only), self-configuration (OVF is designed to use customization parameters that are known in pre-deployment time, which is not realistic in clouds) and deployment constraints (OVF don’t include any mechanism to provide hints for deployment, that are specially relevant in clouds due to business criteria, e.g. the database with the data of my customers can not be deployed outside my country due to regulations).

The RESERVOIR project (focused on federation of clouds at infrastructural level) is doing so. We have analysed the aforementioned problems and we are proposing extensions to OVF to solve them. This is not just theoretical work, because it is backed by an actual cloud middleware prototype. Eventually those extensions could be proposed to DMTF to enhance the OVF specification (now that even Winston Bumpus, the President of the DMTF itself, has expressed the OVF target in cloud, describing the standard as “an ideal cloud migration and deployment package” in the recent SATCCI Workshop) when the appropriated maturity level gets achieved.

By the moment, we have submitted a paper to COMSWARE’09 (authored by Telefónica, SAP, IBM and Sun, four major companies in the ICT industry) performing an early analysis of the problems in detail and proposing solutions (among all the possible ones) to adapt OVF to clouds. It has been accepted for publication, so by mid June the details will be disclosed and we will be very happy to share this knowledge and get feedback for others working on the interesting and hop topic of cloud interoperability.

Comment RSS 7 Responses to “OVF for clouds: one step further”

  1. blog.dsa-research.org » Archives » Interfaces for Private and Public Cloud Computing Says:

    [...] their infrastructural needs. OVF was not designed with cloud computing in mind, so there are issues that need to be solved when applied to this environment, in particular, on automatic elasticity, self-configuration and deployment constraints. In any [...]

  2. Max Says:

    Hi, are you going to post your paper to COMSWARE’09? I would like to see your OVF extensions for the cloud.Max

  3. fermin Says:

    Hi, are you going to post your paper to COMSWARE’09? I would like to see your OVF extensions for the cloud.Max
    Thank you for your comment!
    The conference proceedings are supposed to be publicly available at the ACM digital library. However, I’ve searched for them and it seems that this hasn’t happened yet…
    I’ve contacted conference chairs in order to see what is going on. Stay tunned :)

  4. fermin Says:

    [...] with the possible exception of vCloud API, but which is too obscure yet to have a precise idea about it [...]

    VMware has recently published an early version of the vCloud API, bringing some light to these shadows. It is based on REST and uses OVF as core element to describe deployable services/applications.

    Nice piece of work, in my opinion.

  5. fermin Says:

    Finally, the paper has been made available both in the COMSWARE’09 proceedings at ACM Digital library, and in the RESERVOIR publication web page. Sorry for the delay…

    Any feedback is highly welcome! :)

  6. Morfeo Cloud Technologies » Blog Archive » Are current IaaS Clouds Service-Oriented? Says:

    [...] control the service provisioning lifecycle using a Service Manifest (RESERVOIR’s extension to OVF) that declares the service components (packaged in virtual machine images), service requirements, [...]

  7. Morfeo Cloud Technologies » Blog Archive » The Cloud APIs Storm II: vCloud Says:

    [...] 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. Tags: API, [...]