SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| Open Virtual Machine Format Specification (OVF) Submitted to DMTF. |
Contents
Update 2009-03-23: "Open Virtualization Format (OVF) Version 1.0 Published as a DMTF Standard."
Update 2008-08-11: DMTF announced the availability of the Open Virtualization Format (OVF) Draft Specification (DSP0243) as a Work In Progress. See Open Virtualization Format Specification version 1.0.0b.
[September 11, 2007] Dell, HP, IBM, Microsoft, VMware, and XenSource have submitted the Open Virtual Machine Format Specification (OVF) to the Distributed Management Task Force (DMTF) for further development into an industry standard. The OVF specification describes an open, secure, portable, efficient and extensible format for the packaging and distribution of (collections of) virtual machines. Its goal is to facilitate the automated, secure management not only of virtual machines, but the appliance as a functional unit.
Most importantly, according to the DMTF announcement: "OVF specifies procedures and technologies to permit integrity checking of the virtual machines (VM) to ensure that they have not been modified since the package was produced. This enhances the security of the format and will alleviate security concerns of users who adopt virtual appliances produced by third parties. OVF also provides mechanisms that support license checking for the enclosed VMs, addressing a key concern of both independent software vendors (ISVs) and customers. Finally, OVF allows an installed VM to acquire information about its host virtualization platform and run-time environment, which allows the VM to localize the applications it contains and optimize its performance for the particular virtualization environment."
The proposed OVF uses existing packaging tools to combine one or more virtual machines together with a standards-based XML wrapper, giving the virtualization platform a portable package containing all required installation and configuration parameters for the virtual machines. This allows any virtualization platform that implements the standard to correctly install and run the virtual machines.
As described in the specification Introduction, OVF supports content verification and integrity checking based on industry standard public key infrastructure, and provides a basic scheme for management of software licensing. It supports validation of the entire package and each virtual machine or meta-data component of the OVF during the installation phases of the VM lifecycle management process. It also packages with the appliance relevant user-readable descriptive information that can be use by a virtualization platform to streamline the installation experience. OVF supports both standard single VM packages, and packages containing complex, multi-tier services consisting of multiple interdependent VMs. While OVF is virtualization platform neutral, it also enables platform-specific enhancements to be captured: it supports the full range of virtual hard disk formats used for VMs today, and is extensible to deal with future formats that may arise. OVF also permits the encoding of vendor specific meta-data to support specific vertical markets; it s supports user visible descriptions in multiple locales, and supports localization of the interactive processes
during installation of an appliance, allowing a single packaged appliance to serve multiple market opportunities.
The scope of OVF specification version 1.0 is the packaging and deployment phases of the virtual appliance software life cycle. The management and retirement phases are explicitly not addressed. We intend to extend OVF to assist with automated management of the management and retirement phases as a matter of priority. OVF 1.0 provides the core framework that allows workflow and system-level meta-data to be encoded, stored, and transported. In the OVF package, information can be stored that describes how the appliance is to interact with external processes and systems. Examples of such functionality are appliance upgrade, cataloging, and integrity and/or security checking, and enhanced license management.
The OVF specification is intended to evolve in an appropriate standards organization. However, it is the intention of the authors to ensure that the first version of the specification is implemented in their products, and so the vendors of virtual appliances and other ISV enablement, can develop to this version of the specification.
The charter of the DMTF SVPC (System Virtualization, Partitioning and Clustering Work Group) has been recently updated to reflect this addition of the OVF specification work to their scope. Work on related virtualization management standardization continues in this Work Group, which has released five profiles publicly — with more in the queue awaiting active member participation.
DMTF will continue to develop this technology into a successful, open industry standard and promote it worldwide. "By collaborating on the development of the OVF specification, the group aims to make it easier for IT organizations to pre-package and certify software packaged as virtual machine templates for deployment in their virtualized infrastructure and to facilitate the secure distribution of pre-packaged virtual appliances by ISVs and virtual appliance vendors. Ultimately, the group's goal is to eliminate the need for IT managers to separately install, configure and manage interdependencies between virtualized operating systems and applications, by enabling automated management of the virtual machine lifecycle."
OVF version 1.0 from DMTF [DSP0xxx] is expected by "mid-2008"; a version 0.9 draft is available online, together with a companion White Paper:
OVF: Open Virtual Machine Format Specification. Version 0.9. Reference: 'OVF specification version 0.9'. Copyright © VMware, Inc. and XenSource, Inc. 50 pages. With XML namespaces: http://schemas.dmtf.org/ovf, http://schemas.dmtf.org/ovf/envelope.
Schemas: ANNEX B (pages 25-43) presents the OVF XML Schemas. It is intended that "A normative copy of the XML schemas for this specification may be retrieved by resolving the XML namespace URIs for this specification." The XML schema 'ovf-envelope.xsd' describes overall structure of an OVF descriptor, including the top-level "Envelope" element. The 'ovf-section.xsd' schema describes the abstract section element; this is the base type for OVF extensibility and typically included by other schemas, such as the ovf-hardware.xsd. The ovf-core.xsd schema describes the non-virtual hardware Section types. The 'ovf-virtualhardware.xsd' schema describes the XML representation of the virtual hardware. The 'cim-rasd.xsd' schema describes the XML representation of the CIM ResourceAllocationSettingData. Schema 'cim-vssd.xsd' describes the XML representation of the CIM VirtualSystemSettingData. The 'cim-common.xsd' schema describes the common CIM types. The 'ovf-environment.xsd' schema describes the XML representation of the OVF environment. The Open Virtual Machine Format Whitepaper for OVF Specification. Reference: 'OVF Whitepaper 0.9'. Version 0.9. Copyright © VMware, Inc. and XenSource, Inc. 16 pages. This document gives a detailed description of the motivation and goals behind the design of OVF, and should be read as an accompaniment to the OVF specification of the same revision number.
Summary description from the OVF White Paper:
"The rapid adoption of virtual infrastructure has highlighted the need for a standard, portable meta-data model for the distribution of virtual machines to and between virtualization platforms. Packaging an application together with the operating system on which it is certified, into a virtual machine that can be easily transferred from an ISV, through test and development and into production as a pre-configured, pre-packaged unit with no external dependencies, is extremely attractive.
Such pre-deployed, ready to run applications packaged as virtual machines (VMs) are called virtual appliances. In order to make this concept practical on a large scale it is important that the industry adopts a vendorneutral standard for the packaging of such VMs and the meta-data that are required to automatically and securely install, configure, and run the virtual appliance on any virtualization platform. Virtual appliances are changing the software distribution paradigm because they allow application builders to optimize the software stack for their application and deliver a turnkey software service to the end user. For solution providers, building a virtual appliance is simpler and more cost effective than building a hardware appliance, since the application is pre-packaged with the operating system that it uses, reducing application/OS compatibility testing and certification, and allowing the software to be pre-installed in the OS environment it will run in — by the ISV. For end users, virtual appliances offer an opportunity to dramatically simplify the software management lifecycle through the adoption of a standardized, automated, and efficient set of processes that replace OS and application specific management tasks today.
Whereas current virtual appliances contain a single VM only, modern enterprise applications model service oriented architectures (SOA) with multiple tiers, where each tier contains one or more machines. A single VM model is thus not sufficient to distribute a multi-tier service. In addition, complex applications require install-time customization of networks and other customer specific properties. Furthermore, a virtual appliance is packaged in a run-time format with hard disk images and configuration data suitable for a particular hypervisor. Run-time formats are optimized for execution and not for distribution. For efficient software distribution, a number of additional features become critical, including portability, platform independence, verification, signing, versioning, and licensing terms.
The Open Virtual Machine Format (OVF) specification is a hypervisor-neutral, efficient, extensible, and open specification for the packaging and distribution of virtual appliances composed of one or more VMs. It aims to facilitate the automated, secure management not only of virtual machines but the appliance as a functional unit. For the OVF format to succeed it must be developed and endorsed by ISVs, virtual appliance vendors, operating system vendors, as well as virtual platform vendors, and must be developed within a standards-based framework...
From the user's point of view, an OVF is a packaging format for software appliances. Once installed, an OVF adds to the user's infrastructure a self-contained, self-consistent, software solution for achieving a particular goal. For example, an OVF might contain a fully-functional and tested web-server / database / OS combination, such as a LAMP stack (Linux + Apache + MySQL + PHP), or it may contain a virus checker, including its update software, spyware detector, etc.
From a technical point of view, an OVF is a transport mechanism for virtual machine templates. One OVF may contain a single VM, or many VMs (it is left to the software appliance developer to decide which arrangement best suits their application). OVFs must be installed before they can be run; a particular virtualization platform may run the VM from the OVF, but this is not required. If this is done, the OVF itself can no longer be viewed as a 'golden image' version of the appliance, since run-time state for the virtual machine(s) will pervade the OVF. Moreover the digital signature that allows the platform to check the integrity of the OVF will be invalid.
As a transport mechanism, OVF differs from VMware's VMDK Virtual Disk Format and Microsoft's VHD Virtual Hard Disk format or the open source QCOW format. These are run-time VM image formats, operating at the scope of a single VM disk, and though they are frequently used as transport formats today, they are not designed to solve the VM portability problem; they don't help you if you have a VM with multiple disks, or multiple VMs, or need customization of the VM at install time, or if your VM is intended to run on multiple virtualization platforms — even if the virtualization platforms claim support of the particular virtual hard disk format used...
Conclusion: The OVF specification offers a portable virtual appliance format that is intended for broad adoption across the IT industry. The OVF specification is intended to be immediately useful, to solve an immediate business need, and to facilitate the rapid adoption of a common, backwards compatible, yet rich virtual machine format. OVF is complementary to existing IT management standards and frameworks, and will be further developed within a standards organization. Concretely the OVF specification embraces the diversity of virtual hard disk formats available today, and in so doing reduces users' perceived risk of proprietary 'lock in'. OVF promotes customer confidence through the collaborative development of common standards for portability and interchange of virtual machines between different vendors' virtualization platforms, and promotes best-of-breed competition through its openness and extensibility.
The OVF specification version 1.0 focuses on the immediate need to develop a common standard for 'portability from origin' of virtual machines. An OVF 1.0 compliant appliance that offers type 3 compatibility will correctly install and run on any OVF 1.0 compliant virtualization platform. The limited scope of OVF 1.0 allows the industry to unite around a key, simple use case for portability, and to collaborate in a recognized standards organization to develop specifications that solve more complex use cases, such as V2V...
The following excerpt is unofficial quoted text; see official text in the canonical version 0.9 published specification.
Package Contents: An OVF package shall consist of a single meta-data descriptor and zero or more files... Optionally, an OVF package can have a manifest file (.mf) containing the SHA-1 digests of each file. [As to] Virtual Disk Formats: OVF does not require any specific disk format be used, but to be compliant with this specification, the disk format shall be identified with a unique format URL that refers to an unencumbered specification on how to interpret the disk format. The specification need not be machine readable, but must be static, and unique so it may be used as a key by software reading an OVF to uniquely determine the format of the disk. The specification must be sufficient for someone skilled in the art to properly interpret the disk format for both reading and writing of disk data.
An OVF package can be stored as a single file using the TAR format... OVF restricts the TAR format in that duplication is not allowed within the archive, and furthermore requires that the TAR implementation guarantee that the following three files will be placed at the front of the archive, in specified order: (1) .ovf descriptor file; (2) .mf manifest file - optional; (3) .cert certificate - also optional. This ensures that it is possible to extract those three files without scanning the entire archive. An OVF TAR archive can still be created using standard TAR packaging tools.
OVF Descriptor: All meta-data about the appliance and its contents is stored in the OVF descriptor. This is an extensible XML document for encoding information, such as product details, virtual hardware requirements, and licensing. The semantics, structure, and extensibility framework of the XML descriptor are discussed in Sections 8ff.
OVF Envelope: The envelope is an XML document that describes all meta-data for the virtual machines (including virtual hardware), as well as the structure of the OVF package itself. The outer-most level consists of four parts:
(1) A version indication; (2) A list of all external files that are part of the OVF package, this is typically virtual disk files and potential ISOs, suspend state files, etc; (3) A meta-data part - sections; (4) A description of the content, either a single virtual machine (VirtualSystem) or a configuration of multiple virtual machines (VirtualSystemCollection)...
Virtual Hardware Description: The virtual hardware required by a virtual machine is specified in the VirtualHardware section. This specification supports abstract or incomplete hardware descriptions where only the major devices are described. The hypervisor is allowed to create additional virtual hardware controllers and devices, as long as the required devices listed in the descriptor are realized. This virtual hardware description is based on the CIM classes: VirtualSystemSettingsData and ResourceAllocationSettingsData. The XML representation of the CIM model is based on the WS-CIM Mapping (DMTF DSP0230). The OVF section for virtual hardware is specified in the 'ovf-virtualhardware.xsd' schema...
Core Metadata Sections: The following core meta-data sections are defined:
- DiskSection: Describes meta-information about all virtual disks in the package
- NetworkSection: Description of logical network(s) used in the package
- ResourceAllocationSection: Specifies reserved, limit, shares on a given resource such as memory or CPU for a VirtualSystemCollection
- AnnotationSection: Specifies a free-form annotation on a virtual machine
- ProductSection: Specifies product-information for an appliance, such as product name and version
- PropertySection: Specifies a set of properties that can be configured for a service or virtual machine
- EulaSection: Specifies a license agreement to be shown during import
- StartupSection: Specifies how a VirtualSystemCollection is powered on
- CpuCompatibilitySection: Specifies any specific CPU compatibility requirements for a virtual machine
- OperatingSystemSection: Specifies the installed guest operating system of a virtual machine
- InstallSection: Specifies that the virtual machine needs to be initially booted to install and configure the software
OVF Environment: The OVF environment defines how the guest software and the deployment platform interacts. This environment allows the guest software to access information about the deployment platform, for example, to access the user specified values for the properties defined in the OVF descriptor. The environment also allows the guest software to provide feedback to the deployment platform, for example, during the software installation phase. The environment specification is split into a protocol part and a transport part. The protocol defines the format and semantics of the documents and messages that can be exchanged between the guest software and deployment platform. The transport defines how the information is communicated between the guest software and deployment platform.
Environment Document Protocol: The environment document is an extensible XML document that is provided to the guest software about the environment in which it is being executed. How the document is obtained is transport dependent.
Installation Feedback Protocol: During the installation phase, three operations are defined, for [i] success(): Once the VM has successfully completed its post-install work, it should invoke success, to which it will receive an empty response...[ii] failure(reason): If post-installation fails for some reason, the VM should invoke failure; this will fail the whole process, including terminating the other VMs in the package... [iii] progress(percentage, message): by invoking progress, the VM may inform the deployment platform of the progress of the post-install. The percentage argument gives the completion percentage of the phase, as far as that VM is concerned...
"Group Drafts Virtual Machine Standard." By Rick Merritt. From EE Times (September 10, 2007). "... Specifically, the draft standard defines the so-called TAR file format, originally developed for tape archiving, as a standard file format for virtual machines. It also defines XML metadata formats to be included in a virtual machine to define its hardware and licensing requirements. Using the new standard, one virtual environment could be automatically moved from one system to another when certain set conditions are met without the need for an operator's intervention. Moving jobs easily from one system to another to balance workloads automatically is one the primary goals of virtualization software. In addition, OVF specifies procedures and technologies to permit integrity checking of the virtual machines to ensure that they have not been modified since they were produced. OVF also allows an installed virtual machine to acquire information about its host virtualization platform and run-time environment enabling it to optimize its performance..." "Standard Coming to Virtualization Format." By Stephen Shankland. From CNET News.com (September 10, 2007). "... Cooperating in the effort are VMware, XenSource and Microsoft, which today have separate software for the task of running multiple virtual machines on one computer and separate formats for storing those virtual machines. That storage is an important part of tasks such as backing up data, installing fresh virtual machines from a template, or moving one quiescent virtual machine from one physical computer to another... The move is a notable display of cooperation among competitors. However, the standard doesn't address other aspects of virtualization that could be standardized, such as interfaces to start, stop, move and otherwise control virtual machines." "Enomalism Announces Support for Open Virtual Format (OVF) / Portable Virtual Machine Specification." Enomalism Announcement. Enomalism Inc "announced the support of the Open Virtual Format (OVF) specification submitted by leading virtualization companies targeting an industry standard format for portable virtual machines... Using Enomalism OVF package management interface with our VMcasting technology, the Enomalism dashboard automates the process of installing, upgrading, configuring, and removing software packages..." New Standard Offers Zero-Configuration Virtualisation. Version 1 of Open Virtual Machine Format Expected by mid-2008." By Tom Sanders. VNU Network. September 10, 2007. "The proposed Open Virtual Machine Format (OVF), created by Dell, HP, IBM, Microsoft, VMware and XenSource, provides metadata about virtual machines such as memory, storage and networking requirements. OVF also lists special feature requests like the need for certain chip instruction sets or large demands for floating point or integer calculations. The standard allows for integrity checks, ensuring that a machine has not been altered during storage or shipping. Makers of virtual appliances can use OVF to include licensing information, requiring the user to agree to certain terms and listing the maximum number of allowed installations, for instance. OVF will not enforce the licences, although such technology could be created at a later stage. The standard also allows the creation of application stacks where multiple virtual systems are stored in a single OVF file with one set of metadata... As a file is deployed, the virtual machine monitor could automatically create each of the machines. The group of vendors has submitted OVF as a draft to the Distributed Management Task Force (DMTF) standards body, and a version 1.0 is expected in six to nine months..." [permalink] "Industry Players Working on Standard for VMs." By Eric Bangeman. From ars technica (September 10, 2007). "... Currently, applications such as Virtual PC, VMware Workstation, and XenExpress all use different file formats to maintain and save the state of their respective VMs. That can cause problems for companies that find themselves needing to migrate VMs from one application to another... There are some security safeguards included in the format as well. The draft OVF specification requires integrity checking for the VMs to ensure that they haven't been altered since the last save of the VM's state. OVF will also provide a sort of discovery mode, where VMs will be able to learn about their host platform in order to optimize their performance and localize their application packages... OVF may remove one potential market for PlateSpin, a company that makes 'v2v' software that enables VM images to be converted from one virtualization program's format to another..."
From the DMTF System Virtualization, Partitioning, and Clustering Working Group Charter:
Vendors in the computer industry have provided clusters of machines in order to provide for high availability services, or computational scaling. Vendors have also embraced the need to provide flexibility in the utilization of a single computer's resources by virtualizing these resources for use across multiple virtual machine images on a single computer, or by partitioning the set of resources into subsets each of which is assigned to an individual 'logical' machine.
Whether multiple machine images are available on a single hardware platform, multiple separate machines are joined into a single cluster, or combinations of clusters and virtualization, the management of such aggregations of systems (physical, virtual, clusters) must provide the ability to determine the configuration of the systems, and to manage them with the requisite security, reliability, availability, and extensibility. In addition, simplification of the total overall system management of such multiple machine images must be provided.
(DMTF has chartered the System Virtualization, Partitioning, and Clustering (SVPC) subgroup to create profiles to address current and future customer requirements in the following areas:
- Clusters of computer systems in order to provide high availability, scalability, high-performance
computing, and simplified system management
- Virtualization of computer systems and the resources which comprise them or on which they are dependent
- Image Formats for the provisioning and management of single and groups of virtual systems optionally providing an application or service
- Partitioning of computer systems and the resources which comprise them into multiple separate computer systems
- Generic services in support of high availability and other automation services
The Work Group supports the architectural and technological evolution of CIM and supporting protocols such that they can be embraced throughout the UC standards community (example the rendering of CIM into UML via the
Architecture Work Group)...
The SVPC Work Group is dependent on the Desktop & Mobile work group for the definitions of hardware-centric
desktop and mobile profiles and related CIM model objects. The SVPC work group is dependent on the System
Management Architecture for Server Hardware (SMWG) work group for the definitions of hardware-centric server
and blade specific profiles and CIM model objects. Instances of those hardware-centric objects may be
referenced in the SVPC WG as cluster-aware server resources are modeled.
The SVPC Work Group is dependent on the CIM Core WG for the definitions of general and system-level
abstractions, services and entities to support the SVPC work group's roadmap and specification. Instances of
those general system classes may be referenced in the SVPC WG as cluster-aware concepts are modeled (e.g.,
a cluster file system, multi-instance database, etc.)..."
The SVCP WG has the objective of producing draft specifications that describe a reference model, use cases, a resource model, and interoperable profiles of virtualization. Abstract profiles describing the patterns used in virtualization became draft standards in early 2007. The first phase of concrete and autonomous profiles are excepted to become draft standards in middle of 2007 with a second phase following in 2008. The SVPC WG has the objective of producing draft specifications that describe a reference model, use cases, a resource model, and interoperable profiles of clustering. Phase one is expected to complete by the middle of 2007. Phase two is expected to complete by middle of 2008...
With more than 4,000 active participants representing 44 countries and nearly 200 organizations, the Distributed Management Task Force, Inc. (DMTF) is the industry organization leading the development, adoption and promotion of interoperable management standards and initiatives. DMTF management technologies are critical to enabling management interoperability among multi-vendor systems, tools, and solutions within the enterprise. By deploying solutions that support DMTF standards, IT managers can choose to deploy a mix of systems and solutions that best meet their users' needs, while reducing management complexity and total cost of ownership.
The DMTF's top-level committees, the Technical Committee, Interoperability Committee and the Marketing Committee, oversee the operations of the DMTF's Work Groups. Work Groups, comprised of DMTF members with specific areas of expertise, develop the various
standards, specifications, and other documents in support of managing enterprise and Internet environments.
DMTF standards provide common management infrastructure components for instrumentation, control and communication in a platform-independent and technology neutral way. Management initiatives from the DMTF, as well as other industry organizations are built upon DMTF technologies. These initiatives, which deliver functionality to specific vertical applications and industries, include important implementations such as the DMTF's Common Diagnostic Model (CDM), Desktop and mobile Architecture for System Hardware (DASH) and Systems Management Architecture for Server Hardware (SMASH) Initiatives, and the Storage Networking Industry Association's (SNIA's) Storage Management Initiative Specification (SMI-S).
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
