andy.edmonds.be

The purpose of the guide is to explain OCCI in terms of implementation and integration between the OCCI client and OCCI provider. A number of examples are presented outlining the basic management life cycle of resources managed by an OCCI compliant implementation. It also seeks to make what some might find to be a relatively abstract standard, more real-world and practical. I’ve placed it up on google docs and as ever welcome feedback from one and all!

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.

• RT @rosscooney i am going to CloudCamp Dublin on Sept 15th: http://www.cloudcamp.com/dublin <- me too in reply to rosscooney #
• RT @rosscooney i am going to CloudCamp Dublin on Sept 15th: http://www.cloudcamp.com/dublin <- me too in reply to rosscooney #
• I'm going dark for a week – later netizens and tweeple #

I originally posted this over on the SLA@SOI blog. (PS: apologies for the strange capitalisation, it in fact should be emboldened  – seems to be a “feature” of my current theme)

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.