ISO/IEC 17203:2011

Information technology - Open Virtualization Format (OVF) specification

ISO/IEC 17203:2011 specifies an open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines.

Technologies de l'information — Spécification du format de virtualisation ouvert (OVF)

General Information

• Status: Withdrawn
• Publication Date: 20-Nov-2011
• Withdrawal Date: 20-Nov-2011
• ICS: 35.100.05 - Multilayer applications
• Technical Committee: ISO/IEC JTC 1/SC 38 - Cloud computing and distributed platforms
• Drafting Committee: ISO/IEC JTC 1/SC 38 - Cloud computing and distributed platforms
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 21-Sep-2017
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 17203:2017 - Information technology - Open Virtualization Format (OVF) specification
• Effective Date: 30-Jul-2016

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 17203
First edition
2011-12-01
Information technology — Open
Virtualization Format (OVF) specification
Technologies de l'information — Spécification du format de
virtualisation ouvert (OVF)
Reference number
©
ISO/IEC 2011
©  ISO/IEC 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2011 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 17203 was prepared by ANSI INCITS (as INCITS 469:2010) and was adopted, under a special “fast-
track procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its
approval by the national bodies of ISO and IEC.

© ISO/IEC 2011 – All rights reserved iii

INCITS 469-2010
for Information Technology –
Open Virtualization Format
(OVF) Specification
Developed by
INCITS 469-2010
American National Standard
INCITS 469-2010
American National Standard
for Information Technology –
Open Virtualization Format
(OVF) Specification
Secretariat
Information Technology Industry Council
Approved July 20, 2010
American National Standards Institute, Inc.

Approval of an American National Standard requires review by ANSI that the
American
requirements for due process, consensus, and other criteria for approval have
been met by the standards developer.
National
Consensus is established when, in the judgement of the ANSI Board of
Standard
Standards Review, substantial agreement has been reached by directly and
materially affected interests. Substantial agreement means much more than
a simple majority, but not necessarily unanimity. Consensus requires that all
views and objections be considered, and that a concerted effort be made
towards their resolution.
The use of American National Standards is completely voluntary; their
existence does not in any respect preclude anyone, whether he has approved
the standards or not, from manufacturing, marketing, purchasing, or using
products, processes, or procedures not conforming to the standards.
The American National Standards Institute does not develop standards and
will in no circumstances give an inte rpretation of any A merican National
Standard. Moreover, no person shall have the right or authority to issue an
interpretation of an American National Standard in the name of the American
National Standards Institute. Re quests for interpretations should be
addressed to the secretariat or sponsor whose name appears on the title
page of this standard.
CAUTION NOTICE: This American National Standard may be revised or
withdrawn at any time. The procedures of the American National Standards
Institute require that action be taken periodically to r eaffirm, revise, or
withdraw this standard. Purchasers of American National Standards may
receive current information on all standards by calling or writing the American
National Standards Institute.
CAUTION: The developers of this standard have requested that holders of patents that may be
required for the implementation of the standard disclose such patents to the publisher. However,
neither the developers nor the p ublisher have undertaken a patent search in order to identify
which, if any, patents may apply to this standard. As of the date of publication of this standard
and following calls for the identification of patents that may be required for the implementation of
the standard, no such claims have been made. No further patent search is conducted by the de-
veloper or publisher in respect to any standard it processes. No representation is made or implied
that licenses are not required to avoid infringement in the use of this standard.
Published by
American National Standards Institute, Inc.
25 West 43rd Street, New York, NY 10036
All rights reserved.
No part of this publication may be reproduced in any
form, in an electronic retrieval system or otherwise,
without prior written permission of ITI, 1101 K Street NW, Suite 610
Washington, DC 20005.
Printed in the United States of America

CONTENTS
Foreword .iii
1 Scope . 1
2 Normative References. 1
3 Terms and Definitions . 2
4 Symbols and Abbreviated Terms . 4
5 OVF Packages . 4
5.1 OVF Package Structure. 4
5.2 Virtual Disk Formats. 6
5.3 Distribution as a Single File . 6
5.4 Distribution as a Set of Files . 7
6 OVF Descriptor. 7
7 Envelope Element . 8
7.1 File References. 9
7.2 Content Element . 10
7.3 Extensibility . 11
7.4 Conformance . 12
8 Virtual Hardware Description. 13
8.1 VirtualHardwareSection . 13
8.2 Extensibility . 14
8.3 Virtual Hardware Elements .14
8.4 Ranges on Elements. 17
9 Core Metadata Sections. 19
9.1 DiskSection . 19
9.2 NetworkSection. 21
9.3 ResourceAllocationSection.21
9.4 AnnotationSection. 22
9.5 ProductSection. 22
9.6 EulaSection. 25
9.7 StartupSection . 26
9.8 DeploymentOptionSection . 27
9.9 OperatingSystemSection .29
9.10 InstallSection. 29
10 Internationalization . 29
11 OVF Environment. 31
11.1 Environment Document .31
11.2 Transport. 33
ANNEX A (informative) Symbols and Conventions . 34
ANNEX B (informative) Change Log. 35
ANNEX C (normative) OVF XSD . 36
Bibliography . 37

i
INCITS 469-2010
Tables
Table 1 – XML Namespace Prefixes . 8
Table 2 – Actions for Child Elements with ovf:required Attribute. 14
Table 3 – HostResource Element . 16
Table 4 – Elements for Virtual Devices and Controllers . 17
Table 5 – Core Metadata Sections . 19
Table 6 – Property Types. 25
Table 7 – Property Qualifiers . 25
Table 8 – Core Sections. 33

ii
Foreword (This foreword is not part of American National Standard INCITS 469-2010.)
The Open Virtualization Format (OVF) Specification describes an open, secure, por-
table, efficient and extensible format for the packaging and distribution of software to
be run in virtual machines. The key properties of the format are as follows:
- Optimized for distribution: OVF supports content verification and integrity
checking based on industry-standard public key infrastructure, and it provides
a basic scheme for management of software licensing.
- Optimized for a simple, automated user experience: OVF supports valida-
tion of the entire package and each virtual machine or metadata component
of the OVF during the installation phases of the virtual machine (VM) lifecycle
management process. It also packages with the package relevant user-read-
able descriptive information that a virtualization platform can use to stream-
line the installation experience.
- Supports both single VM and multiple-VM configurations: OVF supports
both standard single VM packages and packages containing complex, multi-
tier services consisting of multiple interdependent VMs.
- Portable VM packaging: OVF is virtualization platform neutral, while also en-
abling platform-specific enhancements to be captured. It supports the full
range of virtual hard disk formats used for hypervisors today, and it is exten-
sible, which allow it to accommodate formats that may arise in the future. Vir-
tual machine properties are captured concisely and accurately.
- Vendor and platform independent: OVF does not rely on the use of a specific
host platform, virtualization platform, or guest operating system.
- Extensible: OVF is immediately useful - and extensible. It is designed to be ex-
tended as the industry moves forward with virtual appliance technology. It
also supports and permits the encoding of vendor-specific metadata to sup-
port specific vertical markets.
- Localizable: OVF supports user-visible descriptions in multiple locales, and it
supports localization of the interactive processes during installation of an ap-
pliance. This capability allows a single packaged appliance to serve multiple
market opportunities.
- Open standard: OVF has arisen from the collaboration of key vendors in the
industry, and it is developed in an accepted industry forum as a future stan-
dard for portable virtual machines.
It is not an explicit goal for OVF to be an efficient execution format. A hypervisor is
allowed but not required to run software in virtual machines directly out of the Open
Virtualization Format.
This standard contains four annexes. Annex C is normative and is considered part of
this standard. Annexes A, B, and D are informative and are not considered part of
this standard.
Requests for interpretation, suggestions for improvement or addenda, or defect re-
ports are welcome. They should be sent to InterNational Committee for Information
Technology Standards (INCITS), ITI, 1101 K Street, NW, Suite 610, Washington, DC
20005.
iii
This standard was processed and approved for submittal to ANSI by INCITS. Com-
mittee approval of this standard does not necessarily imply that all committee mem-
bers voted for its approval. At the time it approved this standard, INCITS had the
following members:
Don Wright, Chair
Jennifer Garner, Secretary
Organization Represented Name of Representative
Adobe Systems, Inc. .Scott Foshee
Steve Zilles (Alt.)
AIM Global, Inc. .Dan Mullen
Charles Biss (Alt.)
Apple Computer, Inc. .Kwok Lau
Helene Workman (Alt.)
David Singer (Alt.)
Distributed Managment Task Force.John Crandall
Jeff Hilland (Alt.)
Electronic Industries Alliance .Edward Mikoski, Jr.
Henry Cuschieri (Alt.)
EMC Corporation .Gary Robinson
Farance, Inc. .Frank Farance
Timothy Schoechle (Alt.)
Google .Zaheda Bhorat
GS1 US.Ray Delnicki
Frank Sharkey (Alt.)
James Chronowski (Alt.)
Mary Wilson (Alt.)
Hewlett-Packard Company .Karen Higginbottom
Paul Jeran (Alt.)
IBM Corporation.Gerald Lane
Robert Weir (Alt.)
IEEE.Bill Ash
Terry DeCourcelle (Alt.)
Jodie Haasz (Alt.)
Bob Labelle (Alt.)
Intel .Philip Wennblom
Grace Wei (Alt.)
Stephen Balogh (Alt.)
Lexmark International .Don Wright
Dwight Lewis (Alt.)
Paul Menard (Alt.)
Microsoft Corporation.Jim Hughes
Dave Welsh (Alt.)
Mark Ryland (Alt.)
John Calhoun (Alt.)
National Institute of Standards & Technology.Michael Hogan
Elaine Barker (Alt.)
Dan Benigni (Alt.)
Fernando Podio (Alt.)
Teresa Schwarzhoff (Alt.)
Wo Chang (Alt.)
Oracle Corporation.Donald R. Deutsch
Jim Melton (Alt.)]
Michael Kavanaugh (Alt.)
Toshihiro Suzuki (Alt.)
Jeff Mischkinsky (Alt.)
Tony DiCenzo (Alt.)
Eduardo Gutentag (Alt.)
Purdue University.Stephen Elliott
Storage Networking Industry Association (SNIA) .Gary Phillips
Arnold Jones (Alt.)
Dave Thiel (Alt.)
iv
Organization Represented Name of Representative
US Department of Defense . Jerry Smith
Dennis Devera (Alt.)
Dave Brown (Alt.)
Leonard Levine (Alt.)
US Department of Homeland Security . Peter Shebell
Gregg Piermarini (Alt.)
The Open Virtualization Format Specification (DSP0243) was prepared by the Sys-
tem Virtualization, Partitioning, and Clustering Working Group of the DMTF.
This specification has been developed as a result of joint work with many individuals
and teams, including:
Lawrence J. Lamers, VMware (Chair)
Steffen Grarup, VMware (Co-Editor)
René W. Schmidt, VMware (Co-Editor)
Simon Crosby, Citrix Systems, Inc.
Ron Doyle, IBM
Mike Gering, IBM
Michael Gionfriddo, Sun Microsystems
Steve Hand, Symantec
Mark Hapner, Sun Microsystems
Daniel Hiltgen, VMware
Michael Johanssen, IBM
John Leung, Intel Corporation
Fumio Machida, NEC Corporation
Andreas Maier, IBM
Ewan Mellor, Citrix Systems, Inc.
John Parchem, Microsoft
Shishir Pardikar, Citrix Systems, Inc.
Stephen J. Schmidt, IBM
Andrew Warfield, Citrix Systems, Inc.
Mark D. Weitzel, IBM
John Wilson, Dell
v
AMERICAN NATIONAL STANDARD INCITS 469-2010

American National Standard
for Information Technology –
Open Virtualization Format
(OVF) Specification
1 Scope
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.
2 Normative References
The following standards contain provisions which, through reference in this text, constitute provisions of
this American National Standard. All standards are subject to revision, and parties to agreements based
on this American National Standard are encouraged to investigate the possibility of applying the most
recent editions of the standards indicated below.
ANSI/IEEE Standard 1003.1-2008, IEEE Standard for Information Technology- Portable Operating
System Interface (POSIX) Base Specifications, Issue 7, Institute of Electrical and Electronics Engineers,
December 2008, http://standards.ieee.org/index.html
DMTF CIM Schema 2.22,
http://www.dmtf.org/standards/cim
DMTF DSP0004, Common Information Model (CIM) Infrastructure Specification 2.5,
http://www.dmtf.org/standards/published_documents/DSP0004_2.5.pdf
DMTF DSP0230, WS-CIM Mapping Specification 1.0,
http://www.dmtf.org/standards/published_documents/DSP0230_1.0.pdf
DMTF DSP1041, Resource Allocation Profile (RAP) 1.1,
http://www.dmtf.org/standards/published_documents/DSP1041_1.1.pdf
DMTF DSP1043, Allocation Capabilities Profile (ACP) 1.0,
http://www.dmtf.org/standards/published_documents/DSP1043_1.0.pdf
IETF RFC1738, T. Berners-Lee, Uniform Resource Locators (URL), December 1994,
http://www.ietf.org/rfc/rfc1738.txt
IETF RFC1952, P. Deutsch, GZIP file format specification version 4.3, May 1996,
http://www.ietf.org/rfc/rfc1952.txt
IETF RFC5234, Augmented BNF for Syntax Specifications: ABNF,
http://www.ietf.org/rfc/rfc5234.txt
IETF RFC2616, R. Fielding et al, Hypertext Transfer Protocol – HTTP/1.1, June 1999,
http://www.ietf.org/rfc/rfc2616.txt
IETF RFC3986, Uniform Resource Identifiers (URI): Generic Syntax,
http://www.ietf.org/rfc/rfc3986.txt
INCITS 469-2010
ISO 9660, 1988 Information processing-Volume and file structure of CD-ROM for information interchange,
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=17505
ISO, ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards,
http://isotc.iso.org/livelink/livelink.exe?func=ll&objId=4230456&objAction=browse&sort=subtype
3 Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
3.1
can
used for statements of possibility and capability, whether material, physical, or causal
3.2
cannot
used for statements of possibility and capability, whether material, physical, or causal
3.3
conditional
indicates requirements to be followed strictly to conform to the document when the specified conditions
are met
3.4
mandatory
indicates requirements to be followed strictly to conform to the document and from which no deviation is
permitted
3.5
may
indicates a course of action permissible within the limits of the document
3.6
need not
indicates a course of action permissible within the limits of the document
3.7
optional
indicates a course of action permissible within the limits of the document
3.8
shall
indicates requirements to be followed strictly to conform to the document and from which no deviation is
permitted
3.9
shall not
indicates requirements to be followed strictly to conform to the document and from which no deviation is
permitted
3.10
should
indicates that among several possibilities, one is recommended as particularly suitable, without
mentioning or excluding others, or that a certain course of action is preferred but not necessarily required
INCITS 469-2010
3.11
should not
indicates that a certain possibility or course of action is deprecated but not prohibited
3.12
appliance
seevirtual appliance
3.13
deployment platform
the product that installs an OVF package
3.14
guest software
the software, stored on the virtual disks, that runs when a virtual machine is powered on
The guest is typically an operating system and some user-level applications and services.
3.15
OVF package
OVF XML descriptor file accompanied by zero or more files
3.16
OVF descriptor
OVF XML descriptor file
3.17
platform
see deployment platform (3.13)
3.18
virtual appliance
a service delivered as a complete software stack installed on one or more virtual machines
A virtual appliance is typically expected to be delivered in an OVF package.
3.19
virtual hardware
the hardware (including the CPU, controllers, Ethernet devices, and disks) that is seen by the guest
software
3.20
virtual machine
the complete environment that supports the execution of guest software
A virtual machine is a full encapsulation of the virtual hardware, virtual disks, and the metadata
associated with it. Virtual machines allow multiplexing of the underlying physical machine through a
software layer called a hypervisor.
3.21
virtual machine collection
a service comprised of a set of virtual machines
The service can be a simple set of one or more virtual machines, or it can be a complex service built out
of a combination of virtual machines and other virtual machine collections. Because virtual machine
collections can be composed, it enables complex nested components.
INCITS 469-2010
4 Symbols and Abbreviated Terms
The following symbols and abbreviations are used in this document.
4.1.1
CIM
Common Information Model
4.1.2
IP
Internet Protocol
4.1.3
OVF
Open Virtualization Format
4.1.4
VM
Virtual Machine
5 OVF Packages
5.1 OVF Package Structure
An OVF package shall consist of the following files:
 one OVF descriptor with extension .ovf
 zero or one OVF manifest with extension .mf
 zero or one OVF certificate with extension .cert
 zero or more disk image files
 zero or more additional resource files, such as ISO images
The file extensions .ovf, .mf and .cert shall be used.
EXAMPLE 1: The following list of files is an example of an OVF package:
package.ovf
package.mf
de-DE-resources.xml
vmdisk1.vmdk
vmdisk2.vmdk
resource.iso
NOTE: The previous example uses VMDK disk files, but multiple disk formats are supported.
An OVF package can be stored as either a single unit or a set of files, as described in 5.3 and 5.4. Both
modes shall be supported.
An OVF package may have a manifest file containing the SHA-1 digests of individual files in the
package. The manifest file shall have an extension .mf and the same base name as the .ovf file and be
a sibling of the .ovf file. If the manifest file is present, a consumer of the OVF package shall verify the
INCITS 469-2010
digests by computing the actual SHA-1 digests and comparing them with the digests listed in the manifest
file.
The syntax definitions below use ABNF with the exceptions listed in ANNEX A.
The format of the manifest file is as follows:
manifest_file = *( file_digest )
file_digest  = algorithm "(" file_name ")" "=" sp digest nl
algorithm   = "SHA1"
digest    = 40( hex-digit ) ; 160-bit digest in 40-digit hexadecimal
hex-digit   = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" |
"b" | "c" | "d" | "e" | "f"
sp      = %x20
nl      = %x0A
EXAMPLE 2: The following example show the partial contents of a manifest file:
SHA1(package.ovf)= 237de026fb285b85528901da058475e56034da95
SHA1(vmdisk1.vmdk)= 393a66df214e192ffbfedb78528b5be75cc9e1c3
An OVF package may be signed by signing the manifest file. The digest of the manifest file is stored in a
certificate file with extension .cert file along with the base64-encoded X.509 certificate. The .cert file
shall have the same base name as the .ovf file and be a sibling of the .ovf file. A consumer of the OVF
package shall verify the signature and should validate the certificate. The format of the certificate file shall
be as follows:
certificate_file  = manifest_digest certificate_part
manifest_digest  = algorithm "(" file_name ")" "=" sp signed_digest nl
algorithm     = "SHA1"
signed_digest   = *( hex-digit)
certificate_part  = certificate_header certificate_body certificate_footer
certificate_header = "-----BEGIN CERTIFICATE-----" nl
certificate_footer = "-----END CERTIFICATE-----" nl
certificate_body  = base64-encoded-certificate nl
; base64-encoded-certificate is a base64-encoded X.509
; certificate, which may be split across multiple lines
hex-digit     = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a"
| "b" | "c" | "d" | "e" | "f"
sp         = %x20
nl         = %x0A
EXAMPLE 3: The following list of files is an example of a signed OVF package:
package.ovf
package.mf
package.cert
de-DE-resources.xml
vmdisk1.vmdk
vmdisk2.vmdk
resource.iso
EXAMPLE 4: The following example shows the contents of a sample OVF certification file, where the SHA1 digest
of the manifest file has been signed with a 512 bit key:
SHA1(package.mf)= 7f4b8efb8fe20c06df1db68281a63f1b088e19dbf00e5af9db5e8e3e319de
7019db88a3bc699bab6ccd9e09171e21e88ee20b5255cec3fc28350613b2c529089
INCITS 469-2010
-----BEGIN CERTIFICATE-----
MIIBgjCCASwCAQQwDQYJKoZIhvcNAQEEBQAwODELMAkGA1UEBhMCQVUxDDAKBgNV
BAgTA1FMRDEbMBkGA1UEAxMSU1NMZWF5L3JzYSB0ZXN0IENBMB4XDTk1MTAwOTIz
MzIwNVoXDTk4MDcwNTIzMzIwNVowYDELMAkGA1UEBhMCQVUxDDAKBgNVBAgTA1FM
RDEZMBcGA1UEChMQTWluY29tIFB0eS4gTHRkLjELMAkGA1UECxMCQ1MxGzAZBgNV
BAMTElNTTGVheSBkZW1vIHNlcnZlcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC3
LCXcScWua0PFLkHBLm2VejqpA1F4RQ8q0VjRiPafjx/Z/aWH3ipdMVvuJGa/wFXb
/nDFLDlfWp+oCPwhBtVPAgMBAAEwDQYJKoZIhvcNAQEEBQADQQArNFsihWIjBzb0
DcsU0BvL2bvSwJrPEqFlkDq3F4M6EgutL9axEcANWgbbEdAvNJD1dmEmoWny27Pn
Ims6ZOZB
-----END CERTIFICATE-----
The manifest and certificate files, when present, shall not be included in the References section of the
OVF descriptor (see 7.1). This ensures that the OVF descriptor content does not depend on whether the
OVF package has a manifest or is signed, and the decision to add a manifest or certificate to a package
can be deferred to a later stage.
The file extensions .mf and .cert may be used for other files in an OVF package, as long as they do
not occupy the sibling URLs or path names where they would be interpreted as the package manifest or
certificate.
5.2 Virtual Disk Formats
OVF does not require any specific disk format to be used, but to comply with this specification the disk
format shall be given by a URI which identifies an unencumbered specification on how to interpret the
disk format. The specification need not be machine readable, but it shall be static and unique so that the
URI may be used as a key by software reading an OVF package to uniquely determine the format of the
disk. The specification shall provide sufficient information so that a skilled person can properly interpret
the disk format for both reading and writing of disk data. It is recommended that these URIs are
resolvable.
5.3 Distribution as a Single File
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).
EXAMPLE: The following example shows a sample filename for an OVF package of this type:
D:\virtualappliances\myapp.ova
For OVF packages stored as single file, all file references in the OVF descriptor shall be relative-path
references and shall point to files included in the TAR archive. Relative directories inside the archive are
allowed, but relative-path references shall not contain “.” dot-segments.
Ordinarily, a TAR extraction tool would have to scan the whole archive, even if the file requested is found
at the beginning, because replacement files can be appended without modifying the rest of the archive.
For OVF TAR files, duplication is not allowed within the archive. In addition, the files shall be in the
following order inside the archive:
1) OVF descriptor
2) OVF manifest (optional)
3) OVF certificate (optional)
4) The remaining files shall be in the same order as listed in the References section (see 7.1).
Note that any external string resource bundle files for internationalization shall be first in the
References section (see clause 10).
INCITS 469-2010
5) OVF manifest (optional)
6) OVF certificate (optional)
Note that the certificate file is optional. If no certificate file is present, the manifest file is also optional. If
the manifest or certificate files are present, they shall either both be placed after the OVF descriptor, or
both be placed at the end of the archive.
For deployment, the ordering restriction ensures that it is possible to extract the OVF descriptor from an
OVF TAR file without scanning the entire archive. For generation, the ordering restriction ensures that an
OVF TAR file can easily be generated on-the-fly. The restrictions do not prevent OVF TAR files from
being created using standard TAR packaging tools.
The TAR format used shall comply with the USTAR (Uniform Standard Tape Archive) format as defined
by the POSIX IEEE 1003.1 standards group.
5.4 Distribution as a Set of Files
An OVF package can be made available as a set of files, for example on a standard Web server.
EXAMPLE: An example of an OVF package as a set of files on Web server follows:
http://mywebsite/virtualappliances/package.ovf
http://mywebsite/virtualappliances/vmdisk1.vmdk
http://mywebsite/virtualappliances/vmdisk2.vmdk
http://mywebsite/virtualappliances/resource.iso
http://mywebsite/virtualappliances/de-DE-resources.xml
6 OVF Descriptor
All metadata about the package 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 dsp8023_1.1.0.xsd XML schema definition file for the OVF descriptor contains the elements and
attributes.
Clauses 7, 8, and 9, describe the semantics, structure, and extensibility framework of the OVF descriptor.
These clauses are not a replacement for reading the schema definitions, but they complement the
schema definitions.
The XML document of an OVF descriptor shall contain one Envelope element, which is the only element
allowed at the top level.
The XML namespaces used in this specification are listed in Table 1. The choice of any namespace prefix
is arbitrary and not semantically significant.
INCITS 469-2010
Table 1 – XML Namespace Prefixes
Prefix XML Namespace
ovf http://schemas.dmtf.org/ovf/envelope/1
ovfenv http://schemas.dmtf.org/ovf/environment/1
rasd http://schemas.dmtf.org/wbem/wscim/1/cim-
schema/2/CIM_ResourceAllocationSettingData
vssd http://schemas.dmtf.org/wbem/wscim/1/cim-
schema/2/CIM_VirtualSystemSettingData
cim http://schemas.dmtf.org/wbem/wscim/1/common
7 Envelope Element
The Envelope element describes all metadata for the virtual machines (including virtual hardware), as
well as the structure of the OVF package itself.
The outermost level of the envelope consists of the following parts:
 A version indication, defined by the XML namespace URIs.
 A list of file references to all external files that are part of the OVF package, defined by the
References element and its File child elements. These are typically virtual disk files, ISO
images, and internationalization resources.
 A metadata part, defined by section elements, as defined in clause 9.
 A description of the content, either a single virtual machine (VirtualSystem element) or a
collection of multiple virtual machines (VirtualSystemCollection element).
 A specification of message resource bundles for zero or more locales, defined by a Strings
element for each locale.
EXAMPLE: An example of the structure of an OVF descriptor with the top-level Envelope element follows:

xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-
schema/2/CIM_VirtualSystemSettingData"
xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-
schema/2/CIM_ResourceAllocationSettingData"
xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
xmlns="http://schemas.dmtf.org/ovf/envelope/1"
xml:lang="en-US">

ovf:href="http://mywebsite/virtualappliances/de-DE-resources.xml"/>

ovf:chunkSize="2147483648"/>
ovf:compression="gzip"/>


INCITS 469-2010


Describes the set of virtual disks




List of logical networks used in the package



A plain-text description of the content










The optional xml:lang attribute on the Envelope element shall specify the default locale for messages
in the descriptor. The optional Strings elements shall contain string resource bundles for different
locales. See clause 10 for more details on internationalization support.
7.1 File References
The file reference part defined by the References element allows a tool to easily determine the integrity
of an OVF package without having to parse or interpret the entire structure of the descriptor. Tools can
safely manipulate (for example, copy or archive) OVF packages with no risk of losing files.
External string resource bundle files for internationalization shall be placed first in the References
element, see clause 10 for details.
Each File element in the reference part shall be given an identifier using the ovf:id attribute. The
identifier shall be unique inside an OVF package. Each File element shall be specified using the
ovf:href attribute, which shall contain a URL. Relative-path references and the URL schemes "file",
"http", and "https" shall be supported, see RFC1738 and RFC3986. Other URL schemes should not
be used. If no URL scheme is specified, the value of the ovf:href attribute shall be interpreted as a
path name of the referenced file that is relative to the location of the OVF descriptor itself. The relative
path name shall use the syntax of relative-path references in RFC3986. The referenced file shall exist.
Two different File elements shall not reference the same file with their ovf:href attributes.
The size of the referenced file may be specified using the ovf:size attribute. The unit of this attribute is
always bytes. If present, the value of the ovf:size attribute shall match the actual size of the referenced
file.
Each file referenced by a File element may be compressed using gzip (see RFC1952). When a File
element is compressed using gzip, the ovf:compression attribute shall be set to “gzip”. Otherwise,
the ovf:compression attribute shall be set to “identity” or the entire attribute omitted. Alternatively,
if the href is an HTTP or HTTPS URL, then the compression may be specified by the HTTP server by
using the HTTP header Content-Encoding: gzip (see RFC2616). Using HTTP content encoding in
combination with the ovf:compression attribute is allowed, but in general does not improve the
INCITS 469-2010
compression ratio. When compression is used, the ovf:size attribute shall specify the size of the actual
compressed file.
Files referenced from the reference part may be split into chunks to accommodate file size restrictions on
certain file systems. Chunking shall be indicated by the presence of the ovf:chunkSize attribute; the
value of ovf:chunkSize shall be the size of each chunk, except the last chunk, which may be smaller.
When ovf:chunkSize is specified, the File element shall reference a chunk file representing a chunk
of the entire file. In this case, the value of the ovf:href attribute specifies only a part of the URL, and
the syntax for the URL resolving to the chunk file is as follows. The syntax uses ABNF with the exceptions
listed in ANNEX A.
chunk-url   = href-value "." chunk-number
chunk-number = 9(decimal-digit)
decimal-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
In this syntax, href-value is the value of the ovf:href attribute, and chunk-number is the 0-based
position of the chunk starting with the value 0 and increases with increments of 1 for each chunk.
Chunking can be combined with compression, the entire file is then compressed before chunking and
each chunk shall be an equal slice of the compressed file, except for the last chunk which may be
smaller.
If the OVF package has a manifest file, the file name in the manifest entries shall match the value of the
ovf:href attribute for the file, except if the file is split into multiple chunks, in which case the chunk-
url shall be used, and the manifest file shall contain an entry for each individual chunk. For chunked
files, the manifest file is allowed to contain an entry for the entire file; if present this digest shall also be
verified.
EXAMPLE 1: The following example shows different types of file references:

ovf:chunkSize="2147483648"/>


EXAMPLE 2: The following example shows manifest entries corresponding to the file references above:
SHA1(disk1.vmdk)= 3e19644ec2e806f38951789c76f43e4a0ec7e233
SHA1(disk2.vmdk.000000000)= 4f7158731ff434380bf217da248d47a2478e79d8
SHA1(disk2.vmdk.000000001)= 12849daeeaf43e7a89550384d26bd437bb8defaf
SHA1(disk2.vmdk.000000002)= 4cdd21424bd9eeafa4c42112876217de2ee5556d
SHA1(resources/image1.iso)= 72b37ff3fdd09f2a93f1b8395654649b6d06b5b3
SHA1(http://mywebsite/resources/image2.iso)=
d3c2d179011c970615c5cf10b30957d1c4c968ad
7.2 Content Element
Virtual machine configurations in an OVF package are represented by a VirtualSystem or
VirtualSystemCollection element. These elements shall be given an identifier using the ovf:id
attribute. Direct child elements of a VirtualSystemCollection shall have unique identifiers.
In the OVF schem
...