Virtual Advisor

The Promise of Open Standards

OVF is more than just another open standard with lofty goals.

• By Chris Wolf
• 08/15/2008

If a committee meets in the woods and designs a standard, but no one is there to implement it, is it still a standard?

Standards have quite a checkered past, with several standards offering little in terms of a real implementation. In the case of too many standards, vendors include an implementation that serves as little more than a marketing checkbox. Oftentimes, vendors push back on standards, saying, "Our proprietary features are what give our product value and differentiate us from the competition." While there's certainly truth in such statements, competing products often include duplicate features with near identical management. That's where the standards have the opportunity to step in and do the IT world some good.

A good example of standards in the virtualization space that have had an immediate positive impact are the Distributed Management Task Force's (DMTF's) System Virtualization and Virtual System common information model (CIM) profiles. The success of the DMTF's effort led participating vendors (including VMware, Citrix, Microsoft and Novell) to develop the Open Virtualization Format (OVF) standard, which recently had its coming out party at the end of June. Since work on the standard was first announced last year, there's been some confusion regarding how OVF will be used, with some making the assumption that OVF will be a new common virtual hard disk format. That's not the case, and OVF will not replace the .VMDK or .VHD virtual hard disk formats. Instead, OVF is used to define a VM's metadata. The VM's metadata is what defines how a VM is configured, and includes information such as:

• Virtual network configuration
• Virtual hard disk requirements (location, logical address, etc.)
• Virtual CPUs
• Virtual memory

Today virtualization vendors store VM metadata information in proprietary configuration files, such as .VMX (VMware) or .VMC (Microsoft). Much of the metadata in the VM configuration file could be stored in an .OVF file instead. In fact, because OVF defines an extensible metadata format, vendors could fully replace their existing proprietary VM metadata files with .OVF files.

VMware has supported OVF since the 2.5 release of the VI client in December 2007, seven months before the OVF spec was finalized. Also, VMware's early OVF support propelled software vendors to begin using OVF to package their virtual software appliances using OVF. VKernel and ManageIQ are two software vendors that are already leveraging OVF today.

Anyone can package a VM using OVF. VMware has made packaging VM appliances to use OVF a snap with its free OVF Tool. With it, you can package an existing VMware VM to use OVF by answering a few questions presented by the OVF Tool (see Figure 1). Once the tool finishes its work, the resultant VM will contain two files: the VM's virtual hard disk file (.VMDK file) and the .OVF metadata file. OVF uses an XML-based schema, and many configuration entries are pretty straightforward.

[Click on image for larger view.]

Figure 1. VMware's open virtualization format tool enables the packaging of existing virtual machines.

VMware has done a nice job getting the OVF ball rolling, but its VI 3.0-based implementation is only capable of using OVF for packaging and importing VMs. Once an OVF-based VM is imported into a VMware environment, its .OVF file will be converted into VMware's proprietary .VMX configuration file.

Several vendors have indicated to me that they're planning to use OVF for managing VM metadata at runtime, so expect OVF to be much more than a tool for importing VM appliances relatively soon.

Why Worry About OVF Today?
OVF is going to be a part of virtualization management for the foreseeable future, so it's a good idea to look for OVF support in virtualization management products you're evaluating today. Granted, the OVF standard was just finished, so there isn't going to be a large vendor ecosystem that supports OVF today. However, all vendors in the virtualization management space should have OVF support on their roadmaps, and those without plans for OVF support should be looked at with caution.

OVF should be part of virtualization planning because architecting virtualization management around OVF will provide the following benefits:

• No vendor lock-in: Management metadata is stored using an industry standard format, making it easier to migrate to another management platform.
• Easy virtual appliance deployment: Expect all virtualization migration tools to support OVF, allowing you to download a VM with one virtual disk format (such as .VMDK) and import it into a VI that uses another format (such as .VHD).
• Improved management: OVF allows you to store all management metadata with a VM, so a VM's management requirements will always remain with it as it traverses the VI.

Work Remains
OVF is off to a good start, but work remains. For example, deploying VM appliances would be easier if we had a standard virtual hard disk format. Vendors admit there's no technical reason that prevents them from using a common virtual hard disk format, yet we still have two formats dominating the market: .VMDK and .VHD. If I'm a vendor, I'd much rather package a single image of my application that can be run on any hypervisor than have to worry about setting up, managing and testing multiple instances in order to support several hypervisors. Granted, hypervisors will require different device drivers inside VM guest OSes, but drivers can be easily replaced with an import tool when a VM is first deployed. In fact, OVF could even advertise driver requirements for each different hypervisor. With a common virtual hard disk format and runtime insertion of device drivers, it would be possible for OVF to be used as a tool that allows a VM to be moved from one hypervisor type to another without the need for conversion. Instead, the VM would just work. Technically, this level of interoperability is possible. It's up to us to continue pushing vendors for a common virtual disk format and we can get there.

Standards-based virtualization management has been fueled by strong user interest, so keep the pressure on the vendors. It's not enough for a vendor to say "We support OVF." Ask for details on how a particular product makes use of OVF. Vendors should be using OVF for runtime metadata and not just as a tool for importing a VM from another hypervisor format. VMware, Citrix and Novell are already supporting OVF. I expect Microsoft to support OVF in its next versions of Hyper-V and System Center Virtual Machine Manager 2008.

If you're in the midst of planning a virtualization deployment, you have more leverage with vendors now than you'll ever have. Vendors that publicly profess to support open standards but have plans for a very weak OVF implementation see lock-in as more important than interoperability, in my opinion. Vendors with particularly good plans for OVF support will offer products that give you the greatest management flexibility moving forward.

There's some exceptionally helpful information on OVF available online. If you're ready to dig deeper into OVF and its potential, I recommend starting at VMware's OVF information page: http://tinyurl.com/2ren7w.