There are many challenges to cloud computing but one core to enabling further value is the removal of lock-in and the enablement of interoperability between cloud services.

To be interoperable means to imbue the common abilities of mobility to cloud service instances, to extract all service instance described by a common representation, to share all cloud service instance related data in and out of providers and to allow cloud service instances work together.

To provide interoperability, it must be present at the lowest level of the cloud stack and so IaaS should firstly be the target, with those interoperability capabilities offered to the upper layer of PaaS where lock-in is even more prevalent. To execute upon this desire, standard specifications need to be agreed upon by both research and industrial domains. In essence this means, in the context of IaaS, to agree upon standardised ways to import and export IaaS customer deployments, to interface with those deployments in a common way during their lifecycle and runtime and to have access to the data supplied and generated and in creating that deployment. These three types of standards must cooperate and integrate as there is no one SDO that can capture research and industry interest and supply the relevant skills all as one. In terms of the IaaS domain this specifically means:

1. Standardised specifications for the import and export of virtualised infrastructure service instances
2. Standardised runtime specification to allow the run-time and lifecycle management of virtualised infrastructure service instances
3. Standardised data access, import and export capabilities to the data that created and was generated by the virtualised service instances

Interoperability is not only a challenge for those in the research and industrial  domains but also for the standards development organisations that solicit input from both the former domains. It is also a challenge that increases in complexity as we move up the commonly accepted cloud computing stack (IaaS –> PaaS –> SaaS). There will be many technical challenges in cloud interoperability below the level of standard specifications but the some more obvious are:

1. Data migration: Cloud service instances can retrieve, consume and process data in ranges greater than terabytes. If one has a cloud service and its related data set is of such an order, current day network technologies are not sufficient to transfer the data in any reasonable time.
2. Service instance migration: A challenge in a similar vein to the previous, what’s of particular interest here is how to maintain and enable  live migration capabilties between cloud providers where paths between two can span many subnets. Work from projects like RESERVOIR is appropriate.
3. Capability Advertisement/Negotiation: Before any migration of service instances can be accomplished, it is necessary that each cloud service provider advertises its service capabilities so that customers wishing to migrate can verify that their current set of capabilities will be satisfied by the target cloud provider. This verification mechanism can also be seen as a negotiation of capabilities, which would lend well to the idea of automated SLAs. Such work from SLA@SOI, OGF’s WS-Agreement would provide a good base line here.

By tackling the challenge presented by interoperability enablement there are a large set of advantages that will emerge, amongst those will be:

• Increased Choice: With many cloud services offering the same interoperability capabilities, the choice of selecting and indeed moving to and from a cloud service provider becomes very much easier. What must be heeded by SDOs is to enable specifications that are easily extendable and that those extensions are easily discovered at runtime. If this is not adhered to by SDOs then provider uptake will be low given that differentiation by price may not be something all providers can compete on. Where they all can is on product differentiation and so SDOs must account for this. Interoperability can only but foster further cloud market place competition.
• Reduced Cost: Interoperability brings with it standardised interfaces and with these, common tools appear. With these tools cognitive and technical complexity is reduced and the number of tools once required to support multiple cloud services of the same type are consolidated. This all goes to reducing technical tooling and education costs.
• Increased Business Agility: Interoperability allows businesses integrate their systems and supporting infrastructures quicker and faster and is a resultant property of increased portability and easier integration through well-known and understood concepts and interfaces.

As of today there are movements under way to tackle the challenge of cloud interoperability. At international levels the efforts of the US NIST initiative and the EU SIENA initiative are leading examples of both research and industry collaborating on this topic. From the view of SDOs, those most active to date are the DMTF, OGF, SNIA and IEEE, where each have a particular study lens on to the area of cloud computing, yet are collaborating together so that they can ensure that they integrate with each other. Within the European Union Framework Programme there are a number of projects seeking to address various aspects within cloud interoperability such as SAIL, GEYSERS, SLA@SOI, RESERVOIR, 4caast and Contrail.

Background: For a period of months, SLA@SOI and RESERVOIR have been collaborating with a goal of architectural and technical integration. Both SLA@SOI and RESERVOIR are each multi-million Euro funded projects under the European Framework Programme 7.

Collaboration activities need communication and commonly agreed structures put in place. From a management view, we, the collaborators, established such elements early in our efforts and this helped us greatly. However, what we then needed was to have complimentary and requisite collaboration from the technical view. This meant having a common and agreed means to communicate technical syntax and semantics between both SLA@SOI and RESERVOIR’s infrastructural layers. These means were supplied to our efforts in the fashion of the Open Cloud Computing Interface (OCCI) [1] specification. It was established early on that the OCCI specification would be a suitable baseline to cater for the horizontal integration of SLA@SOI and RESERVOIR’s infrastructural service layers and hence frame our collaboration at a technical level.

The Open Cloud Computing Interface (OCCI) is a working group formed within the Open Grid Forum [2]. The motivation for initiating this group was the lack of any open standard for the Infrastructure as a Service (IaaS) model-based clouds. The open standardisation process is driven by the following motives:

• Interoperability: the ability to enable different systems integrate with each other. This is an absolute in use cases related to the Intercloud, where two distinctly separate and independent IaaS provider work and orchestrate seamlessly from a customer perspective.
• Portability: the need for easy code reuse in end-user application like cloud clients or portals. Enabling this allows migration from on IaaS to another with minimal impact upon the customer. Where migration through portability is provided and hence lock-in is a non-issue, this focuses the provider on offering compelling and attractive services, which due to the almost commodity-like nature of IaaS often implies competitiveness through lowering of service costs.
• Integration: the idea of “wiring up” IaaS with not only current and modern provider offerings but also to legacy resources and services.

With the focus of providing standardised interfaces to IaaS, the OCCI group defines a RESTful [3] protocol. The goal is to create a simple and elegant interface, which can be easily extended by 3rd parties, and the RESTful approach supports this.

OCCI is a boundary protocol/API that acts as a service front-end to an IaaS provider’s internal infrastructure management framework. It is OCCI that provides for commonly understood semantics and syntax in the domain of customer-to-provider infrastructure management. More so, OCCI is focused on the management of infrastructure hosted in the cloud, in effect, utility computing. The following diagram shows OCCI’s place in the communications chain:

To give this view further context within the collaboration, below we show how RESERVOIR and SLA@SOI would both, quite naturally, integrate together using OCCI as their means for IaaS interoperability.

Further details of this particular integration study were made available in the joint technical report [4].

Open Architectural Issues & Proposed Solutions

As OCCI was identified early as the interface specification that each project would implement, it was not particularly difficult to integrate architecturally. From our review of OCCI, there were a number of issues that might hamper this effort. There were questions raised regarding the suitability of using HTTP headers as a means to transfer serialised data over the network. Where as HTTP headers are a reasonable place to transmit data that has a small payload, inserting data here that has a large payload is not practical. Typically, the most common data that is transferred to OCCI clients are collections of VM representations. This is currently being addressed by the OCCI group.

Also there has been demand for alternative serialisation formats, other than HTTP headers. The OCCI working group is also now investigating and aim to specify how to represent the OCCI model as RDFa [10] within XHTML documents. This would then allow OCCI serialisations rendered within a web browser. An advantage of exposing the attributes and relationships of OCCI managed resources through RDFa is that not only can a web browser consume and display the content but programmatic clients that can extract RDFa [11] can be used to reliably extract data to perform automated tasks and not be subject to issues associated with screen-scraping. A consequence of supporting RDFa is that the OCCI model must be reified as a RDF [12] ontology in order to support and validate RDFa declarations within a XHTML document. By defining a RDF ontology this too adds huge possibilities to the OCCI standard by not only providing a serialisation format that can support a richer and more extensible but could potentially further the cause of linked data and the semantic web.

From our collaboration work, it was found that an area that OCCI does not currently address is atomic, multiple resource provisionings. This means that with the current OCCI specification, it is only possible to provision one resource per request. For some use cases this is not sufficient, as they require that multiple resources be successfully provisioned through one request or not at all. The interim solution used by RESERVOIR was to utilise the Open Virtualisation Format (OVF) [13] specification to express many resources within one request. This work is an example of how other open specifications can be integrated within the OCCI specification. In reference to the previously mentioned OCCI developments, a RDF serialisation, indeed RDFa, format could support and solve this current limitation within OCCI as RDF easily supports multiple resources per request due to its XML heritage.

In order for any provider to be SLA-enabled by SLA@SOI, that provider should ideally offer a means to monitor each service provisioned by its systems. In this case, the provider would offer a monitoring service in parallel to it’s service offering. The exclusion of monitoring considerations in the OCCI specification was found to be an issue when SLA-enabling infrastructural services that implemented the OCCI specification. Although OCCI does not currently offer a means to perform monitoring, other than periodic pull requests to retrieve individual resource metrics, OCCI does not preclude other monitoring specification being used. It is at this point where the two projects, as currently implemented, diverge and so to allow for seamless inter-operable SLA management across the two projects requires that both projects select, just as was done for IaaS management, a standard or common specification for monitoring. Within SLA@SOI, interacting with a service manager is currently performed using access to messaging bus powered by the open standard XMPP [14]. Within, RESERVOIR monitoring information is accessed using the TCloud monitoring API [15]. If the two projects are ever to be interoperable from an SLA management perspective, through horizontal integration then this difference in monitoring approaches needs to be addressed. The suggestion from the horizontal integration working group is two-fold. First, select an API-based monitoring specification that allows asynchronous notifications pushed from the provider. Second, from the learning of implementing the selected API, contribute back to the OCCI working group a compatible specification for an OCCI monitoring extension.

As already noted, a number of OCCI implementations are being actively developed. Once implementations are ready for consumption, it would be appropriate firstly nominate reference implementations and secondly, with those agreed reference implementation perform interoperability tests and report on the results.

Completed Work

Resulting from the collaboration activity, a number of outputs both completed and on going were achieved. A joint technical report entitled “Using Cloud Standards for Interoperability of Cloud Frameworks” [4] was published. This introduced the two collaborating projects, OCCI and outlined a basic use case along with architecture on how the two projects can interoperate.

As RESERVOIR and SLA@SOI had vested interests in OCCI, this resulted in each project producing their own implementation of the OCCI specification. SLA@SOI has an infrastructure service manager, which allows the provisioning of infrastructural services atop its chosen provisioning system, Tashi [5]. RESERVOIR also has exposed OCCI interfaces both at the Service Manager level, through the Claudia project’s [6] implementation and the VEEM level, through the OpenNebula [7] implementation. This potentially allows OCCI interoperation at not only in a horizontal fashion but also, in the context of RESERVOIR’s architecture, a vertical fashion.

As each project worked independently on their implementation of OCCI but still with OCCI as the vehicle of collaboration this resulted in each project supplying feedback to the specification. To date this is largely captured in the section on open architectural issues. It should also be noted that there is another implementation of OCCI in use currently. This implementation belongs to the Istituto Nazionale di Fisica Nucleare (INFN) [8] and was presented at OGF28 [9].

Conclusions

By selecting standardised and commonly agreed interfaces, the integration of both architecture and technology was vastly expedited and simplified and reflects the benefits of standardisation. The use of standards as a tool for rapid and productive collaborations between large projects; be they EU-funded or commercial, cannot be understated. Standards allow for everyone to share a common baseline of functionality and level what would be otherwise an uneven, jagged technology landscape where vast amounts of time, funding and resources are spent just for basic communications to be achieved. With everyone sharing a common baseline of functionality, further functionality can be built upon that, for example in the case of IaaS, Interclouds of IaaS. IaaS cloud brokers with fail over intelligence can be rapidly developed. The horizontal integration working group provided good examples of how to quickly deal with deficiencies in specifications by not re-inventing the wheel, but rather, reusing existing standards e.g. OVF, TCloud. In general, this work showed that it is possible to let two large Cloud-oriented frameworks interoperate even with vastly different architectures and goals. This has the result of paving the way for possible proof of concept demonstrators that have functionality that is greater than the sum of its parts.
[1] Open Cloud Computing Interface working group website http://www.occi-wg.org
[2] Open Grid Forum http://www.ogf.org
[3] Fielding, R.T.: Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine (2000)
[4] Thijs Metsch, Andy Edmonds, Victor Bayon: “Using Cloud Standards for Interoperability of Cloud Frameworks”, http://sla-at-soi.eu/wp-content/uploads/2010/04/RESERVOIR-SLA@SOI-interop-techReport.pdf
[5] Apache Tashi website, http://incubator.apache.org/tashi
[6] The Claudia Platform website, http://claudia.morfeo-project.org
[7] OpenNebula website http://opennebula.org
[8] Istituto Nazionale di Fisica Nucleare website, http://www.infn.it
[9] Michele Orru, Developing Cloud Applications with OCCI, http://www.ogf.org/OGF28/materials/1914/DevelopingCloudapplicationswithOCCI-MicheleOrru-OGF28.pdf
[10] RDFa in XHTML: Syntax and Processing, http://www.w3.org/TR/rdfa-syntax
[11] PyRdfa: RDFa Distiller and Parser, http://www.w3.org/2007/08/pyRdfa/#distill_by_uri
[12] Resource Description Framework (RDF): Concepts and Abstract Syntax, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[13] Open Virtualisation Format, http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf

The pace of development within the OCCI community has been excitedly ever increasing over the past few months. It’s not only been so within the group of people defining the specification but also in the many groups of people and projects implementing OCCI. In our last blog post we mentioned that Eucalyptus will soon have an implementation of OCCI from the good work David Wallom and his FleSSR team in Oxford are doing. In the post we also hinted at something related to OCCI and OpenStack.

As you might be aware, OpenStack is one of the most exciting and vibrant open source Cloud activities on going currently. The OCCI working group has been engaged with OpenStack over the past 3 months with the aim of contributing an implementation of OCCI and we’re happy to say that this will happen with the “Bexar” release of OpenStack. Incidentally, that’s synchronised with the release schedule of Ubuntu 11.04. the You can see the OCCI blueprint on the OpenStack site, which will serve a point of communication for the implementation work.

Not only will OpenStack receive an implementation of OCCI but one of the mainstays of infrastructure management frameworks, libvirt, will also have an implementation of OCCI. This work is being carried out by a team lead by one OCCI community member, Alexander Papaspyrou from TU Dortmund University, Germany.

Platform Computing will provide an OCCI implementation for a German Research Project, DGSI, which allows developers to easily extend their existing applications with an OCCI compliant RESTful interface (RESTify your apps).

Given that OCCI is also implemented in OpenNebula and Apache Tashi (via the SLA@SOI implementation) amongst others (we’re running out of space for this post!), OCCI is fast becoming the API that can provide interoperability between the major Open Source infrastructure management frameworks.

As ever, the OCCI group is always hugely enthusiastic, welcoming and very supportive to people and groups of all types wishing to get involved with OCCI, whether that is through specification contributions or new implementations of it. Curious? Then head on over to IRC (irc.freenode.net #occi), drop a mail on the mailing list or ping some of us on twitter (@dizz, @befreax, @monadic, @papaspyrou).

Stay tuned for more news on OCCI and more implementations of it!

So yes we’ve been quiet but as they say “still waters run deep”. We in OCCI have been deep and active on everything from refining the Core model down through the infrastructure specification and out through the HTTP rendering specification document and, well, things couldn’t be healthier! Following an superb half-week at OGF30 there’s even more great OCCI-related news to share. Coming into OGF30, I was aware of seven OCCI implementations and coming away I knew of twelve! Most notable of those 12 is Eucalyptus who will soon have an implementation through the good work David Wallom and his team in Oxford are doing. You might have noticed a new logo (above) too contributed by Sam You might have also seen the various OCCI articles in the latest ERCIM news and if not go check it out! And there is more, especially in areas related to OpenStack, we’re only dying to share with the community but, soon, very soon you’ll know more!

Much of this work in advocating the adoption and support of OCCI has been carried out by our tireless co-chairs; Thijs, Alexis and I, as well superb support from many people within OGF including Craig Lee (OGF president) and Alan Sill (VP of Standards).

So what was I doing at OGF30 other than working hard and having great fun at the same time with the OCCI guys? Well I presented on the work we’re doing in SLA@SOI. I presented on “Standards-based, SLA-enabled Infrastructure Management”. You can check the presentation out here and I must apologies to those present if I bombarded you with architecture. At least I showed a real live demo! The live demo showed a number of SLA-guaranteed services all managed by OCCI. Incidentally, the OCCI implementation used is open source (BSD) and available on sourceforge. For those not present there’s some screen grabs at the end of the presentation. It’s implemented in the awesome Grails so if you’re interested, take a wander over there. Some interesting pieces coming from SLA@SOI related to OCCI include; a jClouds OCCI implementation, OCCI extensions on Advanced Scheduling and Monitoring.

So if you want to check out what’s going on in OCCI for yourself, why not have a look through the wiki, svn (it’s latex but you can build it ). Come over to IRC (iric.freenode.net #occi). There’s always an OCCI person or more hanging out there and ready to talk.

Finally, as if that wasn’t enough, there was a very interesting DCI-Fed session held where we discussed various use-cases. DCI-Fed (mailing list, wiki) , from a Cloud Computing perspective, is really interesting and exciting. It looks into how various different Cloud Computing providers can interoperate to provide federated services to their clients. Certainly the future!

What’s LTE Advanced?

• 3GPP Release 8 is what is known as Long Term Evolution (LTE). Release 10 is LTE Advanced (3GPP) and is the same as IMT Advanced (ITU).
• Backward compatible with Release 8.
• LTE Advanced satisfies ITU basic requirements and also introduces additional features.
• WiMax2 + LTE Advanced are very similar (I wonder how similar at the low level though?!).
• IMT Advanced is for 4G as IMT-2000 was for 3G.
• IMT Advanced deals only with the radio access network (RAN).
• Differences in spectrum.
• Specification to be released in early 2011.
• All aspects within are large areas. Up to 600 papers submitted in some topic areas.
• ITU to recommend specification, 3GPP to release in parallel all in early 2011.
• “Faster” – there’s lots of increased MHz rates.
• Target deployment example – micro-cellular (“urban micro”).
• General Arch: LTE terminal -> LTE radio access network -> SAE CN (?) -> ISP.
• Release 11 will enhance release 10.
• Release 12 – content open. This is where research-oriented input is required. Example: UE-2-UE (device) communications using network operator resources.
• QoS is sufficient in release 8 for release 10.
• My opinion – Seems to be a want to push carrier technology down into the home from the network (e.g. replace WiFi, with network as a service). You don’t own the equipment network operator does. Network operator has total control. Tiered network rears its head.

Select Discussed LTE Advanced Features

During the talk various features of LTE Advanced were highlighted. Here are some of them that had my ears pricked-up…

Carrier Aggregation

• Very cool. Virtual Carriers created on the fly. Something that was needed on a previous FP7 proposal related to the intersection of cloud computing and mobile networks.
• Compose concurrent carriers of differing bandwidths, no hand-overs needed as in the case of Release 8.
• Aggregation schemes intra-band and inter-band aka spectrum aggregation.
• Applicable to uplink and downlink – asymmetric.
• Cell symmetric but also per UE asymmetric.
• Dynamic allocation of bandwidth QoS.

Enhanced MIMO

• Interesting: access to multiple distributed APs from one UE and coordination.
• Problem: power, more connections to APs more power usage. Example of 3G power usage given (uses MIMO).

HetNet: Enhanced support for heterogeneous networks

• Mix of base stations – femto, pico, macro.
• Originally had hierarchical cell sys (HCS) but is unattractive from regulatory point of view in the case of dense cell structure.
• HetNet can give dense infrastructure.
• Heterogeneity by power output, not necessarily in specification uniformity (appears interoperability is not dealt with?).
• Closed subscriber group – similar to WiFi access point – related to access rights.
• Problem today is there’s not enough uplink in networks – solve perhaps with more pico in a HetNet deployment scenario.

I originally posted this over on the SLA@SOI blog. The subject of the post, a technical report, is one authored by Thijs Metsch (one of my OCCI co-chairs), Victor Bayon (friend and work colleague) and myself.

SLA@SOI and RESERVOIR have been actively collaborating together with the aim of investigating and pursuing the integration of their respective technologies as part of theNEXOF Reference Architecture initiative. One of the outputs of this work has been a technical report that details how cloud standards, such as OCCI, can be used to support the interoperability and integration of cloud frameworks such as those presented by RESERVOIR and SLA@SOI.

What we call Cloud computing today has evolved over many years. It had other names before and many technologies are involved in it. Virtualization, utility computing, and grid technologies are among the most representative.

Cloud offerings can be classified according to the resources they offer ‘as a Service’ (XaaS): Infrastructure as a Service (IaaS) that allows the allocation of virtual machines and storage capacity; Platform as a Service (PaaS) providing users with remote software platforms to run their services; and Software as a Service (SaaS) where applications are moved to the Internet and accessed through web interfaces.

Cloud frameworks on the other hand can be seen as the software environments in which Cloud services can be deployed. Most of the frameworks have automatic and elastic management solutions included: they control the life cycle, placement and Service Level Agreements (SLAs) of a service.

Different frameworks have arisen in the recent past, including commercial proprietary and open frameworks like those developed in the European Commission funded Framework Programme 7 Projects RESERVOIR and SLA@SOI. They consist of similar modules and layers but have different basic architectures. They can be messaging based or client/server, and have a focus on IaaS or SLA management. The different foci leads to different architectures. SLA@SOI targets SLA-driven management, and monitoring the life-cycle of services such as software and infrastructure services. It can also be applied to human-based services. RESERVOIR concentrates on federated clouds, and focuses on the management, interoperability and optimisation within such topologies.

Despite these differences, however, Cloud frameworks typically include a layer to deploy virtual workloads on infrastructure. Allowing frameworks interoperate also enables the use of each other’s unique abilities and functionalities. For example provisioned services could be moved to the Cloud framework which would best fit their needs and their characteristics.

The need to interoperate helps fuel the demand for standards. Only if the frameworks support certain standardized interfaces, can interoperability be achieved. The accompanying paper tries to show the overall setup and ideas behind two Cloud frameworks and includes the description of an upcoming Cloud standard. An architecture which combines all three aspects is also proposed.

Technical Report: Using Cloud Standards for Interoperability of Cloud Frameworks

On a related note, Thijs Metsch presented this document (thanks!), on my behalf, to all those cool OCCI people at OGF28. Here’s the accompanying presentation.

I presented this at SLA@SOI‘s 18 month interim review. It’s a presentation that details the relationship between OCCI and SLA@SOI, what we have done to date and what will be done in the future.

The Open Virtualisation Format (OVF; DSP0243) is a schema for describing a virtual machine or a collection of virtual machines. The initiative is the results of efforts by the Distributed Management Task Force (DMTF) who, amongst other standards, are responsible for the Common Information Model (CIM). Recently OVF version 1.0 was released and with a number of products (Kensho, VMware, Virtualbox) supporting the standard, as well as backing from large vendors (Citrix, VMware, Intel], it is looking like a promising specification in an area that is quite barren of standards, namely cloud infrastructure as a service providers. OVF can be used as a means for customers of an IaaS provider to express their infrastructural needs. Currently within SLA@SOI we use our own schema for making requests against our infrastructure service which then in turn is translated into an internal representation. What this allows us to do is to support multiple schemas and we aim to support the OVF specification. In order to support the OVF specification, we’ve had to dig deep into OVF to assure ourselves that it can accommodate one important requirement of ours – non-functional requirements. By default, OVF does not support this but if you read section 7.3 of the specification you will find that the specification has made it possible to easily extend OVF.

So what’s in OVF? First of all, OVF is XML, so obviously hierarchical in nature. At the core of OVF is the Envelope element and it is this element that contains:

• References – this is a list of external files that are required to satisfy the OVF package. An OVF package does not need local virtual disks or remote ISO files to operate. They can be supplied within the OVF document by using the “ovf:href” attribute of a File element within the Reference section.
• Core Meta-data – this is a list of what are known as Sections. Section elements that are allowed at this level are:
  • NetworkSection – each OVF envelope can have only one or opt not to include the section (zero-or-one). It is here where textual names are given to networks. These work as logical grouping identifiers. Here the attribute of Network, name is required.
    
  • DiskSection – each OVF envelope can have only one or opt not to include the section (zero-or-one). This is a listing of disks used within the OVF document. Each disk can be referred throughout an OVF document by the mandatory “diskId” attribute. Here other attributes include:
    • fileRef – this is an optional reference to virtual disk content
    • capacity – this is required and is the virtual disks maximum capacity
    • capacityAllocationUnits – units in which space is allocated and is optional. By default it is bytes but this can be specified to any unit as listed in the DMTF DSP0004 specification.
    • format – this is a URI that points to a description of the virtual disk format in use
    • populatedSize – this is the estimated populated (space used) size of disk in bytes and is optional
    • parentRef – a reference to a parent disk and is optional
  • DeploymentOptionSection – each OVF envelope can have only one or opt not to include the section (zero-or-one). This section lists a set of configuration options for the contained resources within the OVF document. Each configuration has a textual identifier (e.g. ovf:id”large VM”) which can be related to a particular configuration within the VirtualHardwareSection. A default configuration can be specified by setting ‘ovf:default=”true”‘.
    
• Virtual Machine Specification – the specification of virtual machines in OVF can be presented either as singular or multiple virtual machine specifications. This allows for not only the simple but complex multi-tier applications. A VirtualSystem element represents one virtual machine. A VirtualSystemCollection element represents a list of both VirtualSystems and VirtualSystemCollections. We’ll look further into these two types later.
• Message Bundles – this is a list of message resource bundles for zero or more locales, used for the purpose of localisation and is denoted by the element of Strings

Common Sections of VirtualSystem and VirtualSystemCollection

There are three common Sections used in both VirtualSystem and VirtualSystemCollection:

• AnnotationSection – this section contains any number of user-defined annotations that are relevent to the particular entity. These can be pieces of information that are displayed when opening an OVF document.
• ProductSection – this section specifies product information for an appliance, such as:
  • Product – name of product
  • Vendor – name of product vendor
  • Version – product version, short form
  • FullVersion – product version, long form
  • ProductUrl – URL resolving to product description
  • VendorUrl – URL resolving to vendor description
  • AppUrl – experimental: URL resolving to deployed product instance
  • Icon – experimental: display icon for product
  • Property – this is a property bag of name/value pairs that allow for additional configuration parameters specific to the particular product. These entries are required to specify the type of the value entered (using CIM types DSP0004) and can be flagged if they can be configured by the user at installation time (using the “userConfigurable” boolean attribute).
• EulaSection – this section contains the legal terms for using VirtualSystem/VirtualSystemCollection. This license should be shown during the deployment of the OVF package.

VirtualSystem

A VirtualSystem is the element that describes one virtual machine. Contained in the VirtualSystem are a number of Sections, including the shared Sections of VirtualSytem and VirtualSystemCollection, that are specific to the element:

• VirtualHardwareSection – each VirtualSystem can have only one or opt not to include the section (zero-or-one). The VirtualHardwareSection has an attribute “ovf:transport” that is required. This attribute describes how environment document information can be communicated to the guest software. A VirtualHardwareSection consists of the following elements:
  • System – this element identifies the hypervisor/virtualisation technology that is to be used with the particular VirtualSystem. An enumeration of these types can be found in DSP1042 (for example vmx-4 corresponds to VMWare’s 4th generation virtual hardware).
  • Items – there can be multiple Items in this section. Each item represents a virtual hardware component (e.g. Memory, CPU). The actual type information for each virtual hardware component can be found in DSP1042 in the CIM_ResourceAllocationSettingData class.

  A very interesting aspect is use of Ranges within the VirtualHardwareSection. This allows for minimum and maximum ranges for hardware specifications. For example using Ranges an OVF document can describe that a provider should run a particular appliance with a minimum of 1GB of RAM yet allow the usage of RAM expand and grow to a maximum of 4GB. This allows OVF explicitly capture aspects of elasticity that is core to cloud infrastructure.

• OperatingSystemSection – each VirtualSystem can have only one or opt not to include the section (zero-or-one). This section details the type of operating system installed on the virtual system. The valid operating systems that can be specified here can be found in the CIM_OperatingSystem.OsType.
• InstallSection – each VirtualSystem can have only one or opt not to include the section (zero-or-one). If this section is specified then it signals that the virtual machine needs to be booted once in order to install and/or configure the guest software. The attribute “ovf:initialBootStopDelay” specifies a delay to wait before stopping the machine after configuration is complete. If there are many VirtualSystems with this section it is allowable to run these boot phases concurrently.

VirtualSystemCollection

A VirtualSystemCollection is the element that allows one or many virtual machines in different logical grouping. This element is a list of VirtualSystems and/or VirtualSystemCollections, supporting multi-tier applications and allowing for flexible grouping. Contained in the VirtualSystemCollection are a number of Sections, including the shared Sections of VirtualSytem and VirtualSystemCollection, that are specific to the element:

• VirtualSystemCollection – each VirtualSystemCollection can have many or opt not to include the section (zero-or-many).
  • Or:
• VirtualSystem – each VirtualSystemCollection can have many or opt not to include the section (zero-or-many).
• ResourceAllocationSection – each VirtualSystemCollection can have only one or opt not to include the section (zero-or-one). This describes all resource allocation requirements of a VirtualSystemCollection. This could be used perhaps where a number of appliances are to be executed on the same physical host.
• StartupSection – each VirtualSystemCollection can have only one or opt not to include the section (zero-or-one). This section specifies how a virtual machine collection is powered on and off and the sequence in which each VM should be powered on/off.

Summary

The Open Virtualisation Format is a great step forward in beginning to provide standards in the area of virtualisation. It defines a means to fully describe single or multiple virtual machines. It is also extensible, a very important aspect for SLA@SOI and supports multi-tier applications and the declarative ordering of machines within a multi-tier configuration.

OVF does not however define a standard means in which the virtual disk should be formatted as and the layout of such disks, their endian-ness etc. This requires some recipients of OVF packages to carry out a lengthy process of disk image conversion before the disk images can be utilised. Although, virtual disks, ISO images and other File types can be pointed using only “http” or “https”. This might work for many cases but for infrastructure providers wanting to integrate OVF into their provisioning system, this may require an extension as it might be the case (e.g. in the case of Amazon EC2 AMI identifiers) that appliances and ISOs are pointed to by a unique identifier.