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.