Thoughts on enterprise IT

Dustin Amrhein

Subscribe to Dustin Amrhein: eMailAlertsEmail Alerts
Get Dustin Amrhein: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Virtualization Magazine, Open Web Magazine, Open Source Journal

Blog Post

A Common Open Virtualization Format Specification Misconception

OVF is not about interoperable virtual images

The Open Virtualization Format Specification is not exactly new. The Distributed Management Task Force (DMTF) published the first version in February of 2009 and version 1.1 in January of this year. However, just because the specification has been around for a while does not prevent a very common misunderstanding of the intention of this document.

What is that misunderstanding? Well, it seems there are quite a few folks (both casual observers and those with deep knowledge of virtualization technologies) who believe the goal of the OVF specification is to provide a standard that describes an interoperable virtual image format. That is, they think that a virtual image packaged according to OVF will be able to seamlessly run on multiple hypervisor platforms without requiring any changes.

I suppose the title may lead one to arriving at this misconception, but you only need to look in either the Introduction or Scope section to see the stated purpose of the specification:

The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines.

Notice that the goals of the specification pertain to the portable packaging and distribution of the software within the virtual machine. This statement does not address the portability or interoperability of the virtual machine itself. Further, the key properties of OVF include the following statement:

OVF is virtualization platform neutral, while also enabling platform-specific enhancements to be captured. It supports the full range of virtual hard disk formats used for hypervisors today, and it is extensible, which allow it to accommodate formats that may arise in the future. Virtual machine properties are captured concisely and accurately.

The key piece of information from the above is that OVF supports a wide range of virtual hard disk formats. It does NOT seek to describe a virtual hard disk format that is portable and interoperable across multiple different types of hypervisor platforms. In other words, saying a virtual image adheres to OVF says nothing about that images ability to run on multiple hypervisor platforms.

So, if OVF does not describe virtual images that are interoperable across multiple hypervisor platforms, what does it provide? Perhaps the two most substantial benefits also appear in the key properties section of the specification:

OVF supports content verification and integrity checking based on industry-standard public key infrastructure, and it provides a basic scheme for management of software licensing.

OVF supports validation of the entire package and each virtual machine or metadata component of the OVF during the installation phases of the virtual machine (VM) lifecycle management process. It also packages with the package relevant user-readable descriptive information that a virtualization platform can use to streamline the installation experience.

As we move towards more and more virtual images and appliances, an industry-wide mechanism for content verification is certainly beneficial to all. While basic, the software licensing support allows one to include the pertinent licenses for the components in the virtual image. It also indicates that users should see and have to accept any licenses during the activation process (unattended activation excluded).

The second of the key properties above, especially the bit about packaging descriptive information within the file, is also significant. This property manifests itself most prominently in the OVF Environment section of the specification. This is where OVF describes a standards-based mechanism for the interaction between the system deploying the virtual image and the software on the inside of that virtual image. Simplistically, this section describes a mechanism for supplying information (like input from the user deploying the image) to the guest software in the image. In turn, the guest software can use this information to properly activate and configure the virtual machine.

I'm not sure how widely held the misunderstanding that OVF seeks to provide standards which will produce interoperable virtual images really is. Lately, it seems I have encountered it quite a bit, but that may be coincidental. I'd love to know if you frequently come across the same misconception. In any case, I hope that this post helps to clear up that misconception and point out some of the key intentions of OVF.

More Stories By Dustin Amrhein

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at You can follow him on Twitter at

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.