Open Virtualization Format
The Open Virtualization Format (OVF) is an open standard developed by the Distributed Management Task Force (DMTF) that defines a secure, portable, efficient, and extensible packaging format for distributing software solutions intended to run in virtual machines, enabling interoperability across diverse virtualization platforms.[1] It encapsulates virtual appliances—pre-configured virtual systems including operating systems, applications, and metadata—into a single, self-contained package that supports verification, licensing, and deployment without vendor lock-in.[2] Adopted as the international standard ISO/IEC 17203, OVF addresses the growing need for standardized virtual system mobility in cloud and data center environments.[2] OVF's primary purpose is to facilitate the authoring, transportation, and deployment of virtual systems, allowing software vendors, cloud providers, and IT administrators to package complex multi-tier applications in a platform-neutral way that simplifies distribution and reduces deployment errors.[1] By leveraging the DMTF's Common Information Model (CIM) for resource description, it ensures consistent mapping of virtual hardware and software elements across hypervisors like VMware, Microsoft Hyper-V, and KVM.[2] The format supports both single virtual machines and collections of interconnected systems, promoting automation through descriptive metadata that includes configuration parameters, network bindings, and startup sequences.[1] Key components of an OVF package include an XML-based descriptor file (typically .ovf) that outlines the virtual system's structure, optional manifest and certificate files for integrity and authenticity verification, and the actual virtual disk images or resource files.[1] Packages can be distributed as a directory of files or archived into a single .ova file using TAR format, enhancing ease of transport and archiving.[1] Notable features encompass support for internationalization, encryption of sensitive sections, and extensibility via custom properties, making it suitable for enterprise-scale deployments.[1] The standard has evolved through several versions, with the initial specification released in 2009 and the current version, 2.1.1, published on August 27, 2015, incorporating enhancements for scalability, such as support for large-scale virtual system collections and improved network configuration options.[2] OVF's widespread adoption has been driven by its role in enabling hybrid cloud portability and vendor-agnostic virtualization management, though it is often complemented by related standards like the OVF Environment for runtime parameterization.[1]Overview
Definition and Purpose
The Open Virtualization Format (OVF) is an open standard developed by the Distributed Management Task Force (DMTF) for packaging and distributing virtual machines (VMs) and virtual appliances as single, portable units.[1] Adopted as the international standard ISO/IEC 17203, it defines a standardized, platform-independent format that encapsulates virtual systems along with their configuration metadata, enabling seamless transport and deployment across diverse virtualization environments.[3] The primary purposes of OVF include promoting portability of VMs across different hypervisors and platforms, thereby reducing vendor lock-in and facilitating interoperability in virtualization ecosystems.[1] By providing descriptive metadata for automated configuration, validation, and customization, OVF simplifies the deployment process, allowing users to install pre-packaged software solutions efficiently without manual reconfiguration.[2] This approach supports use cases such as publishing virtual appliances for distribution, transporting them between systems, and archiving them for long-term storage.[1] A virtual appliance, as defined in OVF, is a pre-configured software stack that includes one or more VMs, complete with an operating system, applications, dependencies, and virtual hardware specifications, designed for turnkey deployment.[1] For instance, it might bundle a web server application with its required database and middleware, ensuring all components are optimized and interdependent elements are preserved during transfer.Key Components
The Open Virtualization Format (OVF) package is composed of core elements designed to encapsulate virtual machines or appliances for portable distribution across virtualization platforms. At its foundation is the OVF descriptor, an XML file that provides essential metadata about the package, including virtual hardware requirements such as CPU, memory, and network configurations, as well as mappings to disk images and deployment parameters. This descriptor serves as the central blueprint, enabling consumers to understand and configure the virtual environment without proprietary knowledge.[1] Virtual disk images form another critical component, containing the actual operating system, applications, and data state of the virtual machine. OVF supports a variety of disk formats, including VMDK (Virtual Machine Disk) from VMware and VHD (Virtual Hard Disk) from Microsoft, provided they adhere to open or unencumbered specifications identifiable by URI. These images are referenced in the descriptor rather than embedded, allowing flexibility in storage and transport while preserving the VM's runtime integrity.[1] To ensure security and validation, OVF includes optional manifest files and certificate files. Manifest files, typically with a .mf extension, list SHA-1 or SHA-256 cryptographic hashes for all files in the package, allowing verification of integrity during transfer or deployment to detect tampering. Certificate files, with a .cert extension, contain X.509 digital certificates used to sign the manifest, thereby authenticating the package's origin and protecting against unauthorized modifications. These security features are particularly vital for enterprise distributions.[1] OVF extends beyond single virtual machines by supporting virtual appliances, which package multiple interconnected VMs within one descriptor using elements like VirtualSystem for individuals or VirtualSystemCollection for groups. This enables complex, multi-tier applications to be deployed as cohesive units. Additionally, the format's extensibility allows for custom properties and sections, such as vendor-specific metadata, through optional XML extensions that can be marked as required or ignored by consumers.[1] For packaging and transport, OVF content is typically organized as a directory structure or a single TAR archive file with the .ova extension, facilitating easy distribution via file systems, HTTP, or other protocols. The package employs standard MIME types, such as application/ovf for the descriptor and application/x-virtual-machine for disks, to support web-based handling and interoperability. This structure underpins the deployment process by providing a self-contained, platform-agnostic bundle.[1]History and Development
Origins and Initial Release
The Open Virtualization Format (OVF) originated from collaborative efforts within the Distributed Management Task Force (DMTF) to address the fragmentation in virtualization technologies during the mid-2000s. In September 2007, leading industry players including Dell, HP, IBM, Microsoft, VMware, and XenSource submitted a draft specification to the DMTF's Platform Management Division, specifically under the System Virtualization, Partitioning, and Clustering Working Group, which functioned as the Virtualization Special Interest Group (SIG). This initiative aimed to create an open standard for packaging and distributing virtual machines, breaking down proprietary silos that had emerged as virtualization gained traction, particularly following VMware's early market dominance with its Virtual Machine Disk (VMDK) format and the rise of competitors like Microsoft's Virtual Server and Xen-based hypervisors.[4] The primary motivations stemmed from the need to enable seamless export and import of virtual appliances across heterogeneous environments, reducing vendor lock-in and simplifying deployment for independent software vendors (ISVs) and enterprises. At the time, proprietary formats hindered portability, complicating security, licensing, and lifecycle management of virtual systems, especially as virtualization adoption surged for server consolidation and data center efficiency. The proposing companies emphasized that OVF would provide a platform-independent package combining descriptive metadata with virtual disk images, supporting initial focus on x86 architectures to facilitate broad interoperability without requiring deep integration into specific hypervisors.[4][5] Early collaborations were formalized through this 2007 submission, which included a foundational whitepaper outlining the format's structure and benefits, co-authored primarily by representatives from VMware and XenSource with endorsements from the other contributors. This document served as the precursor to the full specification, highlighting use cases for secure, extensible packaging and garnering DMTF approval to advance it as an industry standard. Subsequent development involved iterative feedback from the working group, leading to the first public draft releases in mid-2008.[6][5] The initial release of OVF 1.0 occurred as a draft standard in June 2008 (version 1.0.0a), with preliminary updates through July and August, emphasizing basic packaging for virtual systems on x86 platforms. This draft laid the groundwork for content verification, integrity checking via public key infrastructure, and extensible descriptors, before the final 1.0 specification was published in February 2009. The effort marked a pivotal step in standardizing virtualization portability, influencing subsequent ISO adoption as IEC/ISO 17203.[5][7]Versions and Evolution
The Open Virtualization Format (OVF) has evolved through several specification versions managed by the Distributed Management Task Force (DMTF), with each iteration building on the previous to enhance portability, deployment flexibility, and integration with broader virtualization and cloud standards.[2] The initial versions focused on foundational packaging for virtual machines, while later updates addressed cloud-native requirements and interoperability. Standardization milestones include adoption as an international standard under ISO/IEC 17203 in 2017, which formalized OVF 2.0 elements for global use. OVF 1.0, released as a DMTF standard on February 22, 2009 (following a preliminary version in September 2008), introduced basic support for packaging single or multiple virtual machines, including descriptions of virtual hardware requirements, references to disk images in formats like VMDK, and an XML-based descriptor file for metadata and deployment parameters.[5] This version emphasized platform neutrality, content integrity via SHA-1 digests, and extensibility through custom sections, enabling secure distribution of virtual appliances as either directory structures or single OVA archives.[5] Backward compatibility was not a concern at this stage, as it established the core envelope schema. OVF 1.1, published on January 12, 2010, extended the 1.0 foundation with features for improved usability and standards alignment, including internationalization support through localizable messages via theovf:msgid attribute and Strings elements for multiple languages.[8] It added a StartupSection to specify power-on and power-off sequences for virtual machines, with attributes like ovf:order, ovf:startDelay, and ovf:stopAction for ordered dependencies.[8] Enhanced error handling came via the ovf:required attribute on extensions, allowing consumers to flag unsupported features without full package rejection, while deeper alignment with DMTF's Common Information Model (CIM) ensured consistent mapping of resources like virtual hardware.[8] This version maintained full backward compatibility with 1.0 packages, with no deprecations noted.
OVF 2.0, released on August 22, 2013 (as version 2.0.1), marked a significant shift toward cloud deployment scenarios, introducing sections for dynamic resource management and network abstraction.[9] Key additions included the NetworkSection with port profiles for logical network mappings and bandwidth reservations, the ResourceAllocationSection for defining policies on CPU, memory, and I/O limits/shares across virtual machine collections, and enhanced DeploymentOptionSection for selectable configurations tailored to cloud environments.[9] Support for OVF Environments was expanded via the ProductSection for runtime property injection and the EnvironmentFilesSection for supplementary data files, enabling better guest-platform interaction during deployment.[9] Backward compatibility with 1.x was preserved, though 2.0 packages could include new elements ignored by older tools, with optional warnings for unrecognized sections.
A minor update, OVF 2.1.1, was issued on August 27, 2015, primarily as a maintenance release incorporating errata, clarifications to sections like DiskSection and VirtualHardwareSection, and refinements for tool compatibility without introducing major features.[1] It ensured seamless parsing of 2.x packages by 1.x consumers through improved error/warning mechanisms.[1] As of 2025, no major versions beyond 2.1.1 have been released, with DMTF providing ongoing maintenance through the Open Virtualization Format Working Group; OVF continues to integrate with complementary standards like OASIS TOSCA for orchestrating cloud applications that incorporate virtual appliances.[10] No deprecations have rendered prior versions obsolete, emphasizing OVF's design for long-term interoperability across virtualization ecosystems.[1]
Technical Design
Package Structure
The Open Virtualization Format (OVF) package organizes virtual machine components into a standardized, portable structure that facilitates distribution and deployment across virtualization platforms. At its core, an OVF package consists of a descriptor file, optional manifest and certificate files, and supporting resources such as virtual disks, all arranged to ensure self-containment and verifiability.[1] In a directory-based package, the hierarchical structure begins with a root directory containing the primary descriptor file, typically named with a.ovf extension (e.g., myvm.ovf), which serves as the central XML document encapsulating the package's metadata and references to other elements. Accompanying this are zero or more disk or resource files (e.g., .vmdk for virtual disks), an optional manifest file with a .mf extension (e.g., myvm.mf), and an optional certificate file with a .cert extension (e.g., myvm.cert). The manifest and certificate, if present, must reside as siblings to the descriptor in the root directory, while disk files can be placed in subdirectories for organization, though paths are relative to the descriptor's location. This layout ensures that all components are logically grouped, with the descriptor acting as the entry point for parsing the package.[1]
File relationships within the package are defined through the descriptor's XML structure, where the References element lists all referenced files using File elements identified by unique ovf:id attributes, including details like file size, compression type (e.g., gzip), and hashing information. The DiskSection then links to these files via ovf:fileRef attributes that match the ovf:id values, specifying how virtual disks are associated with virtual hardware in the VirtualSystem or VirtualSystemCollection elements. This referential mechanism allows the package to interrelate components without embedding their contents directly in the descriptor, promoting efficiency and modularity; for instance, a disk image might be referenced by ID "disk1" and used by multiple virtual systems if applicable. Namespaces in the XML, such as ovf for core elements and extensions like rasd for resource allocation, enable extensibility while maintaining these interconnections.[1]
OVF packages support two primary variations for distribution: directory-based, where files are stored as a loose collection in a folder, and single-file format using the .ova extension, which bundles the entire package into a compressed TAR archive in USTAR format. In the .ova variant, the descriptor must appear first in the archive, followed by files in the order listed in the References element, allowing consumers to extract and validate sequentially without full unpacking. Compressed content is handled by indicating gzip compression in the descriptor's File elements, where the reported size reflects the compressed bytes.[1]
Validation of the package ensures completeness and integrity through a multi-step process leveraging the manifest and certificate. The manifest file contains SHA-256 (or legacy SHA-1) digests for every file referenced in the References element, formatted as lines like SHA256(disk1.vmdk)=<hexdigest>, which consumers compute and compare against the package files to detect tampering or corruption. If a certificate is included, it provides an X.509 public key and a digital signature over the manifest using DSA or RSA, allowing verification of the package's authenticity by checking the signature chain against trusted authorities. This process confirms not only the unaltered state of all components but also the package's origin, with incomplete or mismatched elements rendering the package invalid for deployment.[1]
Descriptor Schema
The Open Virtualization Format (OVF) descriptor is an XML document that provides metadata for the virtual machine (VM) package, adhering to schemas defined by the Distributed Management Task Force (DMTF).[1] The schema uses the primary namespaceovf (http://schemas.dmtf.org/ovf/envelope/2 for version 2.0) for core elements and rasd (http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData) for resource allocation descriptions, enabling structured representation of VM configurations.[1] This design ensures portability across virtualization platforms by specifying hardware requirements, disk references, and deployment parameters in a standardized format.[5]
The root element is <ovf:Envelope>, which encapsulates package metadata including virtual systems and sections for content description.[1] Key sections within the envelope include <ovf:VirtualSystem>, which defines individual VMs with attributes like ovf:id and ovf:name for identification.[5] The <ovf:VirtualHardwareSection> details hardware components such as CPU cores (via <rasd:Item> with rasd:VirtualQuantity), memory allocation (in bytes), and device connections.[1] File references are managed in the <ovf:References> section, listing disk images and other artifacts with elements like <ovf:File ovf:id="..." ovf:href="..." ovf:size="...">.[5] Deployment options appear in <ovf:DeploymentOptionSection>, specifying configurable parameters such as resource limits with <ovf:Configuration ovf:id="..."> elements.[1]
Specific elements highlight hardware and software details. The <ovf:Disk> element, used in <ovf:DiskSection>, represents virtual disks with attributes including ovf:diskId (unique identifier), ovf:capacity (allocation in bytes), ovf:format (URI like "http://www.vmware.com/interfaces/specifications/vmdk.html#sparse"), and optional ovf:populatedSize for actual data size.[1] Networks are defined in <ovf:NetworkSection> via <ovf:Network ovf:name="...">, providing logical names for connectivity mappings.[5] The <ovf:ProductSection> conveys licensing and product information, featuring sub-elements like <ovf:Product> (name), <ovf:Vendor> (provider), <ovf:Version> (release), and <ovf:Property ovf:key="..." ovf:type="string" ovf:value="..."> for configurable settings such as application parameters.[1]
Schema evolution introduces enhancements across versions. In version 1.0, the focus was on basic VM packaging with core sections like <ovf:VirtualSystem> and <ovf:DiskSection>, without advanced deployment parameterization.[5] Version 2.0 expands this by adding <ovf:DeploymentOptionSection> to support cloud-oriented configurations, including resource scaling options and environment-specific parameters, while maintaining backward compatibility through updated namespaces (e.g., /envelope/2).[1]
Extensibility is facilitated through substitution groups for custom sections, allowing vendors to define additional metadata without breaking validation.[1] For instance, proprietary extensions can use elements like <other:CustomSection xsi:type="ovf:Section_Type" ovf:required="false"> in the envelope's section list, with the ovf:required attribute (defaulting to true) indicating mandatory processing.[5] This open content model, combined with xs:any wildcards in the schema, supports vendor-specific data such as incident tracking or encryption details while preserving core OVF integrity.[1]