The Open Virtualization Format (OVF) standard has been under development at the Distributed Management Task Force (DMTF) for several years. The primary goal has been to define an “open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines.” In short, OVF provides a standard way to store VM’s and associated meta-data outside the context of a hypervisor.

For the better part of two years, Citrix Labs has been developing an open source library called Project Kensho to import and export OVF packages to and from a XenServer storage repository (SR). In addition to the current OVF standard, Project Kensho supports disk encryption to protect sensitive data during transport. Version 1.3 of the project has now been included as part of the Xen Cloud initiative from Xen.org. Project Kensho also forms one pillar of the Citrix XenConvert tool for physical-to-virtual (P2V) and virtual-to-virtual (V2V) system conversions.

While producing Kensho, the Labs team has seen both the promise of OVF and the challenges that remain.  On the “promise” side, the specification provides for building out complex packages of virtual systems that can act in concert to realize an end-to-end multi-tiered system. The packages can be compressed and digitally signed for storage or transport. Such packages also provide an interesting unit of workload that could be managed through a typical system life cycle.

Even so, many challenges remain. In broad terms, here are a few of them:

  1. OVF portability – OVF packages produced by virtualization platform vendors tend to work only in the originating environment. Note that Project Kensho is arguably the most vendor-neutral OVF tool available, as it can consume virtual system image output from several vendors and inject many of them into Microsoft’s Hyper-V in addition to XenServer.
  2. OS portability – Each hypervisor brings its own guest OS and driver requirements. Building a single image for multiple environments remains a challenge.
  3. Licensing – Not all software vendors are prepared to license products in a virtual world. This has a variety of implications for the utility of OVF in the data center and for ISV’s.
  4. System maintenance – Images need patches and upgrades over time. This is not a problem unique to OVF. However, a core part of the problem is the need for meta-data descriptors of systems, and OVF can therefore be part of the solution.

In subsequent entries, I plan to discuss portability, licensing, and system maintenance in more detail. What other challenges have you seen with OVF? Feel free to leave your thoughts and experiences in the comments section.