If you’ve worked with recent versions of VMware virtual infrastructure, Converter, or Workstation, you may be familiar with the fact that these products have the native ability to work with virtual machines in the Open Virtualization Format, or OVF for short. OVF is a Specification governed by the DMTF (Distributed Management Task Force) which to me sounds a lot like RFCs which provide standards for protocols and communication across compute platforms – basically SOPs for how content is delivered on the internet as we know it today.
So if there’s one standard, why is it that when I choose to create an OVF (Export OVF Template in the vSphere Client), I’m prompted to create either an OVF or an OVA? If the OVF is an OVF, then what’s an OVA?
Personally, I’ve seen both formats, typically when deploying packaged appliances. The answer is simple: Both the OVF and the OVA formats roll up into the Specification defined by the DMTF. The difference between the two is in the presentation and encapsulation. The OVF is a construct of a few files, all of which are essential to its definition and deployment. The OVA on the other hand is a single file with all of the necessary information encapsulated inside of it. Think of the OVA as an archive file. The single file format provides ease in portability. From a size or bandwidth perspective, there is no advantage between one format or the other as they each tend to be the same size when all is said and done.
The DMTF explains the two formats on pages 12 through 13 in the PDF linked above:
An OVF package may be stored as a single file using the TAR format. The extension of that file shall be .ova (open virtual appliance or application).
An OVF package can be made available as a set of files, for example on a standard Web server.
Do keep in mind that which ever file type you choose to work with, if you plan on hosting them on a web server, MIME types will need to be set up for .OVF, OVA, or both, in order for a client to download them for deployment onto your hypervisor.
At 41 pages, the OVF Specification contains a surprising amount of detail. There’s more to it than you might think, and for good reason:
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.
Open, meaning cross platform (bring your own hypervisor). Combined with Secure and Portable attributes, OVF may be one of the key technologies for intracloud and intercloud mobility. The format is a collaborative effort spawned from a variety of contributors:
Simon Crosby, XenSource
Ron Doyle, IBM
Mike Gering, IBM
Michael Gionfriddo, Sun Microsystems
Steffen Grarup, VMware (Co-Editor)
Steve Hand, Symantec
Mark Hapner, Sun Microsystems
Daniel Hiltgen, VMware
Michael Johanssen, IBM
Lawrence J. Lamers, VMware (Chair)
John Leung, Intel Corporation
Fumio Machida, NEC Corporation
Andreas Maier, IBM
Ewan Mellor, XenSource
John Parchem, Microsoft
Shishir Pardikar, XenSource
Stephen J. Schmidt, IBM
René W. Schmidt, VMware (Co-Editor)
Andrew Warfield, XenSource
Mark D. Weitzel, IBM
John Wilson, Dell
Take a look at the OVF Specifications document as well as some of the other work going on at DTMF.
Have a great and safe July 4th weeekend, and congratulations to the Dutch on their win today in World Cup Soccer. I for one will be glad when it’s all over with and our Twitter APIs can return to normal again.
OVF isn’t the nirvana that it’s reported to be, it’s missing the most important detail – the disk image.
While it does a great job of describing metadata the disk image is poorly defined. Vendors can use their own disk format – eg. vmdk, vhd, qcow, raw, etc so unless your hypervisor supports them all (and to-date no one does) then you have to convert the image before you import.
Then there’s the issue of drivers, what drivers and configuration do you load in the VM? VMware uses scsi emulation or their own PV driver for disk, Xen uses IDE or their own drivers, KVM uses …….. So even if you can read the image you have to swap out the drivers that were installed, or make sure that all OVFs include VMware, Xen, Microsoft, KVM, drivers and config files.
for a homogeneous hypervisor world OVF is fine, but in reality it’s fundamentally flawed
@Ian
Understood, but the current version of the OVF standard is 1.0. I expect improvements will come in time.
Lets see if it comes, it’s against some people’s (VMW) interest to provide this kind of portability
that’s why it was blocked before
It is a wondeful explaination, but base on my experience when export as OVF files is faster than OVA more than 10 time. does any one are facing this problem like me, it take very long time to export to OVA
Nice little gotcha on OVA buried in the Converter manual notes. If you have a volume over 9 GB in the OVA you are creating, it will successfully create it but the entire file will be corrupt. Wonderful feature there. Thanks VMWare! 😉
Great info on this site. We have started playing around with vmware and looking to scale down some of our back office servers. Thanks.
“Lets see if it comes, it’s against some people’s (VMW) interest to provide this kind of portability
that’s why it was blocked before” right. that’s why vmware / vbox / xenserver all have working ovf support and the oss people don’t.
or maybe it’s, by chance, nothing more than a lame excuse because writing ovf def’s is no fun?
“An OVF package may be stored as a single file using the TAR format. The extension of that file shall be .ova (open virtual appliance or application).”
Correction is : OVA package
“An OVA package may be stored as a single file using the TAR format. The extension of that file shall be .ova (open virtual appliance or application).”