The Open Virtualization Format (OVF) specification is a standard being developed within the Distributed Management Task Force (DMTF) association to promote an open, secure, portable, efficient, and extensible format for the packaging and distribution of software to be run in virtual machines.

DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. Members and non-members may reproduce DMTF specifications and documents for uses consistent with this purpose, provided that correct attribution is given.

IBM sees a lot of potential in the development of the OVF standard, especially since it supports the ability to create an open environment that defines the standard means to represent and distribute virtual machine/virtual appliance content. IBM has been active in the formation of the standard specification. To further promote the adoption of OVF based packages, we have developed tools to assist those interested in representing virtual machine/virtual appliances in OVF distributable format.

In this article, we outline the standard and demonstrate the Open Virtualization Format Toolkit.

OVF's place in the virtual appliance life cycle

As stated in Section 1.4 of the Open Virtualization Format White Paper (see the Resources section later in this article for a link), the software life cycle for virtual appliances follows this pattern:

1. Develop
2. Package and distribute
3. Deploy
4. Manage
5. Retire

After the development phase (Step 1), services (one or more VMs and the necessary configuration and deployment metadata) are packaged into the OVF format (Step 2). The packaged components can be third-party bits. In the deployment phase (Step 3), the OVF package is installed. The management and retirement phases (Step 4 and 5) are specific to both the nature of the contents in the OVF package and to the particular virtualization products you're using.

OVF 1.0 addresses the package and distribute, and deploy phases.

Back to top

Elements in the OVF standard

Three key elements defined by the OVF standard:

• The OVF package
• The OVF descriptor
• The OVF environment file

Let's discuss them in detail.

The OVF package

At its core, an OVF package is a distribution package that consists of the following:

• One OVF descriptor file (.ovf). This is commonly referred to as the OVF envelope and is largely the subject of this tooling support. The OVF descriptor file defines the content and requirements of the packaged virtual appliance in support of a successful and consistent deployment of this package. The OVF descriptor file follows an XML format.
• Zero to one OVF manifest file (.mf). The manifest file contains the SHA-1 digests of the individual files in the OVF package. The purpose of the manifest is to provide for data integrity of the package.
• Zero to one OVF certification file (.cert). An OVF package may be signed by signing the manifest file. The signature of the digest is stored in a .cert file along with the base64-encoded X.509 certificate. The purpose of the certificate is to ensure package authenticity.
• Zero to many disk image files. These files represent the virtual disks that support the defined virtual image(s) or appliance. More generally, the package includes artifacts needed by the appliance, including virtual disks, localized language resources, and other artifacts.

The OVF descriptor

The envelope descriptor describes all metadata for the virtual machine(s) (including virtual hardware) that make up this OVF package.

The envelope consists of the following parts:

• A version indication defined by the XML namespace URI.
• A list of file references to all external files that are part of this OVF package defined by the References element and its File child elements. These are typically virtual disk files, ISO images, and internationalization resources.
• Appliance-level metadata defined by section elements detailing things such as networks and virtual disks.
• A description of the appliance content, which is either a single virtual machine (VirtualSystem element) or a collection of multiple virtual machines (VirtualSystemCollection element).
• A specification of message resource bundles for zero or more locales defined by a Strings element for each locale.

Figure 1 shows the construct of part of an OVF envelope.

(See the full image.)

The OVF envelope is created and used in the package and distribute phases of the virtual appliance life cycle.

The OVF environment

The OVF environment is an XML document that is generated by an OVF deployment platform at the time an OVF package is being deployed and in turn, made available to guest software within the deployed virtual system(s). The intent of the OVF environment document is to provide the virtual system guest software (of a deployed OVF package) property variable information that can be used to "customize" the guest virtual system(s). Authors of OVF package descriptors (the OVF envelope) indicate what custom properties will require variable input. During the deployment activity of an OVF package, the deployment platform collects the values to be associated to the custom property keys and constructs the OVF environment document.

The OVF environment is used in the deployment phase of the virtual appliance life cycle.

Back to top

Open Virtualization Format Toolkit highlights

The Open Virtualization Format Toolkit provides a set of Eclipse plug-ins, as well as a standard Java™ API, to help you create virtual appliance packages in the new standards-based format, the Open Virtualization Format. The OVF Toolkit helps to package and distribute the virtual appliance in conformance to the OVF standard.

This toolkit provides an easy-to-use editor that performs the tasks of creating the required package descriptors, ensuring compliance to the syntactic and semantic requirements of the standard. It also provides capabilities to export the package files in the two formats allowed by the OVF standard: as a single TAR file in Open Virtual Appliance format or as a set of files.

In support of this new editing capability, this package offers the set of Eclipse plug-ins necessary to extend your existing development environment.

The following sections highlight the various aspects and usage scenarios of the OVF composition tool. If you want to follow along, download the toolkit from alphaWorks and install it on your machine.

Specification coverage and validation

The OVF specification provides a schema that details the semantics of an OVF envelope XML instance document, as well as a written specification that details semantics that extend beyond what is expressed in the schema. The OVF Toolkit provides support that will generate OVF-compliant instance documents and distribution packages that adhere to the OVF schema, as well as to the written specification. Coverage items include:

• Cardinality adherence for element data as well as for required attributes
• Referential integrity for element relationships
• Data type integrity
• Field enumeration integrity for bounded types
• Support for semantics of the written specification in addition to the schema syntax

The OVF specification includes the ability to describe within the envelope XML instance documents single-virtual-machine content definitions, as well as multiple-virtual-machine content definitions. The OVF composition tool provides support for creating, editing, and packaging either of these types of instance documents along with their supporting files.

Authoring a new OVF envelope

In many cases, it may be desirable to create an OVF envelope from scratch. As we mentioned earlier, one of the Eclipse artifacts present within the composition tool is a new editor that provides just this capability. In essence, you create a new file within your Eclipse workspace as you would any file within an Eclipse IDE. What is new is the type of file: It's called an Envelope Model.

The steps to create a new OVF envelope are:

1. Create a new project (or use an existing project) to hold the OVF envelope files if one does not already exist.

2. Create a new Envelope Model file within the project using the File/New/Other menu action.

3. At this point you will have a skeleton OVF envelope opened within the new editor. Bear in mind that the majority of the OVF metadata is to be added after the new file creation.

4. Add additional content into the OVF envelope by highlighting an element within the editor; right-click and select either New Child or New Sibling, depending on the content to be added.

5. All of the typical editing commands work as expected, including cut, copy, and paste. In addition, a view you will want to have open is the Properties view. Open this view through either the context menu for an OVF object or the Window/Show View/Properties menu action. The Properties view provides the attribute names and their corresponding values for the selected element within the tree editor. This view is the place where you can change data values for the selected attribute. In Figure 6, a new File element was added under the References section; when selected, its corresponding attributes are visible and changeable within the Properties view.

That's it for creating a new OVF envelope. When you save the file you are editing, the envelope is serialized into standard OVF format and if desired, can be opened up with either the OVF envelope editor or any other editor capable of viewing XML files (if you wish to inspect the XML representation of the envelope).

Figure 8 shows the envelope in the envelope editor.

Figure 9 shows the envelope in a standard text editor displaying the serialized XML.

Import/edit a proprietary VM descriptor

We recognize that many x86-based virtual machines exist and are hosted by one of the VMware hypervisor products. In cases like this, it will be desirable for you to create the OVF envelope metadata and OVF distribution package that represent these previously built virtual machines.

To make this composition scenario a bit easier, you can use a new Import capability that has been developed (to be more specific, the Import VMware VMX Configuration File). By using this new import capability, you can have the base OVF envelope metadata generated from the VM configuration data file, which can then be subjected to additional editing changes depending on the final OVF package desired. In a fashion similar to the Composing New scenario, you will be creating an OVF envelope as a new file into a workspace-based project. The following figures illustrate the basic steps to perform this type of import.

First select File/Import from the main menu options:

Then select the VMX configuration file to "import" along with the designation of the target location within the workspace where you would like the generated OVF envelope to be placed:

After pressing Finish the import processing will analyze the VMX configuration file and generate the appropriate OVF envelope structure. In addition to the OVF metadata, a file link will be created in the workspace project for each VMDK (virtual disk) file in support of subsequent OVF package generation, providing a full "round trip" generation scenario. Figure 12 displays the envelope editor opened for the generated OVF envelope.

Export an OVF package

One of the primary goals of the OVF specification is to define a standard means of package distribution that is efficient, secure, and portable. To this extent, the specification defines two primary types of package formats:

• Packaging as a single TAR file (open virtual appliance or .ova format)
• Packaging as a file set (multiple file format)

The OVF composition tool supports both of these distribution formats thorough the services of Export processing. Exporting an OVF package as a file set or as an .ova TAR archive is essentially the same process from within the OVF composition tool; a dialog selection along the way controls which package format is desired. As a reference to how OVF packages can be produced in support of distribution, we present the following scenario.

An OVF package can be represented as a set of files or as a single file using the TAR format. If the OVF package is the single-file format, the extension of that file should be .ova (open virtual appliance or application).

For OVF TAR archives, the files are created in the following order inside the archive:

1. .ovf descriptor file.
2. The remaining files are in the same order as listed in the References section. Note that any external string resource bundle files for internationalization shall be first in the References section.
3. .mf manifest file (if the user chooses).
4. .cert certificate file (if the user chooses package signing).

If the manifest or certificate files are present, they are placed at the end of the archive. For deployment, the ordering restriction ensures that it is possible to extract the OVF descriptor from an OVF TAR file without scanning the entire archive. The TAR format used complies with the USTAR (Uniform Standard Tape Archive) format as defined by the POSIX IEEE 1003.1 standards group.

To export an OVF package from the OVF composition tool, you select the file export menu command:

Next you select and load the OVF descriptor file that defines the OVF envelope metadata and its respective files. If you selected an .ovf file before invoking the export wizard, the wizard will pre-load it for you.

The next step is to indicate what processing you would like performed for the files that are contained within the OVF envelope References section. There are a number of things to consider at this point of the export process:

• Are the files to be packaged along with the envelope and other optional files? (This is required for local file references but optional for http or https protocols.)
• Are any of the files resource translation bundles? (They need to be ordered first in the file list.)
• Do you want to have a manifest file created? (This will cause the file digests to be calculated.)
• Do you want the file sizes calculated (or recalculated)?

Figure 15 illustrates the dialog where you indicate your file-processing options:

Following the file-processing step, you indicate the destination directory to export the OVF into and whether you want to export a set of files or an .ova TAR file archive.

The final step (Figure 17) allows you to save any changes that might be relevant to the OVF envelope based on earlier option selections (update file sizes). After this step, you will have the exported OVF package ready for distribution.

You can save the wizard settings at this point. If you do, a file with the extension .ovfPackage will be created in your workspace. Later on, you can select this file and start the export wizard with all the settings restored.

Back to top

Conclusion

In this article we've described the Open Virtualization Format standard, an open, secure, portable, efficient, and extensible format to help you package and distribute the software you want to run on virtual machines. We've also:

• Discussed OVF's role in the life cycle of the common virtual appliance.
• Outlined the three critical support elements of the standard—OVF's package, descriptor, and environment file—and demonstrated what they do and how to use them.
• Given you a tour of Open Virtualization Format Toolkit, highlighting such features as specification coverage and validation, authoring OVF envelopes, importing and editing proprietary VM descriptors, and exporting OVF packages.

Now, all that remains is for you to dive into the Resources section below and continue your education into the Open Virtualization Format and the toolkit that supports its functions.

Resources

Learn

• Take a look at some of the really important documents:
  • The Open Virtualization Format Specification 1.0.0 PDF is the core reference doc for the standard.
  • The OVF white paper PDF is the essential narrative for those wanting to understand OVF.
  • The OVF envelope descriptor schema outlines the XML schema for OVF descriptors.
  • Likewise, the OVF environment schema outlines the XML schema for OVF environment files.
  
  
• "Virtual Linux" (developerWorks, December 2006) is a good entry point to learn about virtualization methods, architectures, and implementations.
  
  
• "Discover the Linux Kernel Virtual Machine" (developerWorks, April 2007) gives you more details on Linux and virtualization, including its architecture and advantages.
  
  
• Considering the abundance of technologies that come together in this article, you may want a shortcut to the developerWorks Open source zone (especially the Eclipse project section), the Java zone, and the XML zone.
  
  

Get products and technologies

• Download the Open Virtualization Format (OVF) Toolkit from alphaWorks.
  
  
• Download Eclipse 3.4 if you don't have it already.
  
  
• Download some OVF sample descriptors.
  
  

Discuss

• A fresh Open Virtualization Format Toolkit forum is waiting for your questions on developerWorks.
  
  

About the authors

Steve Schmidt is a senior software engineer currently working in the IBM Software Group Advanced Design and Technology team in Research Triangle Park, N.C. He has been with IBM for more than 27 years and has been involved in many aspects of computer engineering, ranging from mainframe operating systems to personal computing to industry solutions. Recently, he has focused on virtualization technologies and the exciting possibilities they hold.

Mike Gering is a senior software engineer for the IBM Software Group Advanced Design and Technology group in Research Triangle Park, N.C. He has been a professional programmer for more than 30 years, witnessing the demise of punched cards and the ascendancy of personal computing. His current interests include model-driven development and virtualization. He enjoys finding and making good hacks, in the traditional, benevolent sense of the word.

Andrew R. Freed is an Advisory Software Engineer at IBM's Research Triangle Park facility in North Carolina. He has spent the last two years on the WebSphere Remote Server team, specializing in monitoring solutions. He is the author of the WRS Data Provider.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• OVF's place in the virtual appliance life cycle
• Elements in the OVF standard
• Open Virtualization Format Toolkit highlights
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Open source on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers