ISO/IEC 17203:2017

INTERNATIONAL ISO/IEC
STANDARD 17203
Second edition
2017-09
Information technology — Open
Virtualization Format (OVF)
specification
Technologies de l'information — Spécification du format de
virtualisation ouvert (OVF)
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – 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.
The procedures used to develop this document and those intended for its further
maintenance are described in the ISO/IEC Directives, Part 1. In particular the different
approval criteria needed for the different types of document should be noted. This
document was drafted in accordance with the editorial rules of the ISO/IEC Directives,
Part 2 (see http://www.iso.org/directives).
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. Details of any patent rights identified during the development
of the document will be in the Introduction and/or on the ISO list of patent declarations
received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users
and does not constitute an endorsement.
For an explanation on the voluntary nature of Standard, the meaning of the ISO specific
terms and expressions related to conformity assessment, as well as information about
ISO’s adherence to the WTO principles in the Technical Barriers to Trade (TBT) see the
following URL: Foreword – Supplementary information
This document was prepared by ANSI (as INCITS 469‐2015) and was adopted, under a
special “fast‐track procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information
technology.
The list of all currently available parts of ISO/IEC 17203 series, under the general title
Information technology, can be found on the ISO web site.

© ISO/IEC 2017 – All rights reserved iii

CONTENTS
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 3
4  Symbols and abbreviated terms . 5
5  OVF package . 5
5.1  OVF package structure . 5
5.2  Virtual disk formats . 6
5.3  OVF package options . 6
5.4  Distribution as a set of files . 7
6  OVF descriptor . 7
7  Envelope element . 8
7.1  File references . 8
7.2  Content element . 9
7.3  Extensibility . 10
7.4  Conformance . 10
8  Virtual hardware description . 11
8.1  VirtualHardwareSection . 11
8.2  Extensibility . 12
8.3  Virtual hardware elements . 12
8.4  Ranges on elements . 14
9  Core metadata sections . 16
9.1  DiskSection . 17
9.2  NetworkSection . 18
9.3  ResourceAllocationSection . 18
9.4  AnnotationSection . 19
9.5  ProductSection . 19
9.6  EulaSection . 21
9.7  StartupSection . 22
9.8  DeploymentOptionSection . 23
9.9  OperatingSystemSection . 24
9.10  InstallSection . 24
9.11  EnvironmentFilesSection . 24
9.12  BootDeviceSection . 25
9.13  SharedDiskSection . 25
9.14  ScaleOutSection . 26
9.15  PlacementGroupSection and PlacementSection . 27
9.16  EncryptionSection . 28
10  Internationalization . 29
10.1  Internal resource bundles . 29
10.2  External resource bundles . 29
10.3  Message content in external file . 30
11  OVF environment and OVF environment file . 30
11.1  Transport media . 31
11.2  Transport media type . 31
ANNEX A (informative) Symbols and conventions . 33
ANNEX B (normative) OVF XSD . 34
ANNEX C (informative) OVF mime type registration template . 35
ANNEX D (informative) OVF examples . 37
D.1  Examples of OVF package structure . 37
D.2  Examples of distribution of files . 37
D.3  Example of envelope element . 38
D.4  Example of file references . 38
D.5  Example of content element . 39
D.6  Examples of extensibility. 39
D.7  Examples of VirtualHardwareSection . 40
© ISO/IEC 2017 – All rights reserved i

D.8  Examples of virtual hardware elements . 40
D.9  Example of ranges on elements . 41
D.10  Example of DiskSection . 42
D.11  Example of NetworkSection . 42
D.12  Example of ResourceAllocationSection . 42
D.13  Example of annotation . 43
D.14  Example of Product section . 43
D.15  Example of EULA section . 43
D.16  Example of StartupSection . 44
D.17  Example of DeploymentOptionSection . 44
D.18  Example of OperatingSystemSection . 45
D.19  Example of InstallSection . 45
D.20  Example of EnvironmentFilesSection . 45
D.21  Example of BootDeviceSection . 45
D.22  Example of SharedDiskSection . 46
D.23  Example of ScaleOutSection . 46
D.24  Example of PlcementGroupSection . 47
D.25  Example of EncryptionSection . 48
D.26  Example of internationalization . 49
D.27  Example of message content in an external file . 50
D.28  Example of environment document . 51
ANNEX E (informative) Network port profile examples . 52
E.1  Example 1 (OVF descriptor for one virtual system and one network with an inlined
network port profile) . 52
E.2  Example 2 (OVF descriptor for one virtual system and one network with a locally
referenced network port profile) . 53
E.3  Example 3 (OVF descriptor for one virtual system and one network with a network
port profile referenced by a URI) . 55
E.4  Example 4 (OVF descriptor for two virtual systems and one network with two network
port profiles referenced by URIs) . 57
E.5  Example 5 (networkportprofile1.xml) . 59
E.6  Example 6 (networkportprofile2.xml) . 60
ANNEX F (informative) Deployment considerations . 61
F.1  OVF package structure deployment considerations . 61
F.2  Virtual hardware deployment considerations . 61
F.3  Core metadata sections deployment considerations . 61

ii    © ISO/IEC 2017 – All rights reserved

Tables
Table 1 – XML namespace prefixes . 8
Table 2 – Actions for child elements with ovf:required attribute . 12
Table 3 – HostResource element . 13
Table 4 – Elements for virtual devices and controllers . 14
Table 5 – Core metadata sections . 16
Table 6 – Property types . 21
Table 7 – Property qualifiers . 21
Table 8 – Availability attributes . 27
Table 9 – Affinity Attributes . 28
Table 10 – Allowed combinations of scoped affinity and availability . 28
Table 11 – Core sections for OEF . 31

© ISO/IEC 2017 – All rights reserved iii

AMERICAN NATIONAL STANDARD INCITS 469-2015

American National Standard
for Information Technology –
Open Virtualization Format
(OVF) Specification
1 Scope
The Open Virtualization Format (OVF) Specification describes an open, secure, efficient and
extensible format for the packaging and distribution of software to be run in virtual systems.
The OVF package enables the authoring of portable virtual systems and the transport of virtual
systems between virtualization platforms. This version of the specification (2.1) is intended to allow
OVF 1.x tools to work with OVF 2.x descriptors in the following sense:
 Existing OVF 1.x tools should be able to parse OVF 2.x descriptors.
 Existing OVF 1.x tools should be able to give warnings/errors if dependencies to 2.x
features are required for correct operation.
If a conflict arises between the schema, text, or tables, the order of precedence to resolve the conflicts
is schema; then text; then tables. Figures are for illustrative purposes only and are not a normative
part of the standard.
A table may constrain the text but it shall not conflict with it.
The profile conforms to the cited CIM Schema classes where used. Any requirements contained in the
cited CIM Schema classes shall be met. If a conflict arises the CIM Schema takes precedence.
The profile conforms to the cited OVF XML Schema. It may constrain the schema but it shall not
conflict with it. If a conflict arises the OVF XML Schema takes precedence.
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.
The following referenced documents are indispensable for the application of this document. For dated
or versioned references, only the edition cited (including any corrigenda or DMTF update versions)
applies. For references without a date or version, the latest published edition of the referenced
document (including any corrigenda or DMTF update versions) applies.
DMTF DSP0004, Common Information Model (CIM) Infrastructure Specification
d_documents/DSP0004_2.7.pdf
2.7, http://www.dmtf.org/standards/publishe
DMTF DSP0223, Generic Operations 1.0,
http://www.dmtf.org/standards/published_documents/DSP0223_1.0.pdf
DMTF DSP0230, WS-CIM Mapping Specification
1.0, http://www.dmtf.org/sites/default/files/standards/documents/DSP0230_1.0.2.pdf
DMTF DSP1001, Management Profile Specification Usage Guide 1.1,
http://www.dmtf.org/standards/published_documents/DSP1001_1.1.pdf
© ISO/IEC 2017 – All rights reserved 1

INCITS 469-2015
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
DMTF DSP1047, Storage Resource Virtualization Profile
1.0, http://www.dmtf.org/standards/published_documents/DSP1047_1.0.pdf
DMTF DSP1050, Ethernet Port Resource Virtualization Profile 1.0,
http://www.dmtf.org/standards/published_documents/DSP1050_1.0.pdf
DMTF DSP1057, Virtual System Profile
1.0, http://www.dmtf.org/standards/published_documents/DSP1057_1.0.pdf
DMTF DSP8023, OVF XML Schema Specification for OVF Envelope
2.0, http://schemas.dmtf.org/ovf/envelope/2/dsp8023_2.0.xsd
DMTF DSP8027, OVF XML Schema Specification for OVF Environment
1.1, http://schemas.dmtf.org/ovf/environment/1/dsp8027_1.1.xsd
DMTF DSP8049, Network Port Profile XML Schema,
http://schemas.dmtf.org/ovf/networkportprofile/1/dsp8049_1.0.xsd
IETF RFC1738, T. Berners-Lee, Uniform Resource Locators (URL), December
1994, http://tools.ietf.org/html/rfc1738
IETF RFC1952, P. Deutsch, GZIP file format specification version 4.3, May
1996, http://tools.ietf.org/html/rfc1952
IETF RFC2616, R. Fielding et al, Hypertext Transfer Protocol – HTTP/1.1, June
1999, http://tools.ietf.org/html/rfc2616
IETF Standard 66, Uniform Resource Identifiers (URI): Generic Syntax,
http://tools.ietf.org/html/rfc3986
IETF Standard 68, Augmented BNF for Syntax Specifications: ABNF,
http://tools.ietf.org/html/rfc5234
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=1750
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=su
btype
ISO/IEC/IEEE 9945:2009: Information technology -- Portable Operating System Interface (POSIX®)
Base Specifications, Issue 7
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50516
W3C, XML Schema Part 1: Structures Second Edition. 28 October 2004. W3C Recommendation.
URL: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
W3C, XML Schema Part 2: Datatypes Second Edition. 28 October 2004. W3C Recommendation.
URL: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
W3C, XML Encryption Syntax and Processing Version 1.1, 13 March 2012, W3C Candidate
Recommendation
http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313/
FIPS 180-2: Secure Hash Standard (SHS)
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
2    © ISO/IEC 2017 – All rights reserved

INCITS 469-2015
3 Terms and definitions
In this document, some terms have a specific meaning beyond the normal English meaning. Those
terms are defined in this clause.
The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not
recommended"), "may," "need not" ("not required"), "can" and "cannot" in this document are to be
interpreted as described in ISO/IEC Directives, Part 2, Annex H. The terms in parenthesis are
alternatives for the preceding term, for use in exceptional cases when the preceding term cannot be
used for linguistic reasons. Note that ISO/IEC Directives, Part 2, Annex H specifies additional
alternatives. Occurrences of such additional alternatives shall be interpreted in their normal English
meaning.
The terms "clause", "subclause", "paragraph", and "annex" in this document are to be interpreted as
se 5.
described in ISO/IEC Directives, Part 2, Clau
The terms "normative" and "informative" in this document are to be interpreted as described
in ISO/IEC Directives, Part 2, Clause 3. In this document, clauses, subclauses, or annexes labeled
"(informative)" do not contain normative content. Notes and examples are always informative
elements.
The terms defined in DSP0004, DSP0223, and DSP1001 apply to this document. The following
additional terms are used in this document.
3.1
authoring function
the creation of the OVF package
3.2
chassis
a placement policy as defined in the class CIM_Chassis
3.3
conditional
indicates requirements to be followed strictly to conform to the document when the specified
conditions are met
3.4
deployment function
a function the result of which is a prepared virtual system
3.5
geographic
a placement policy referring to a geographic location (e.g., a country, a state, a province, a latlong)
3.6
guest software
the software that runs inside a virtual system
© ISO/IEC 2017 – All rights reserved 3

INCITS 469-2015
3.7
mandatory
indicates requirements to be followed strictly to conform to the document and from which no deviation
is permitted
3.8
optional
indicates a course of action permissible within the limits of the document
3.9
rack
a placement policy as defined in the class CIM_Rack
3.10
site
a placement policy as defined in Access, Terminals, Transmission and Multiplexing (ATTM);
Broadband Deployment - Energy Efficiency and Key Performance Indicators; Part 2: Network sites;
Sub-part 1: Operator sites, Technical Report, ETSI TR 105 174-2-1 V1.1.1 (2009-10)
3.11
OVF package
a single compressed file or a set of files that contains the OVF descriptor file and may contain
associated virtual disks, operational metadata, and other files
3.12
OVF descriptor
an XML file that validates to DSP8023 and provides the information needed to deploy the OVF
package
3.13
virtualization platform
the hypervisor on which the virtual systems run
3.14
virtual appliance
a service delivered as a software stack that utilizes one or more virtual systems
3.15
virtual hardware
the processor, memory and I/O resources provided by a virtualization platform that supports a virtual
system
3.16
virtual system
as defined in the Virtual System Profile plus the guest software if any
3.17
virtual system collection
a collection of virtual systems
3.18
virtualization management
the software that performs resource allocation and management of virtual systems
4    © ISO/IEC 2017 – All rights reserved

INCITS 469-2015
4 Symbols and abbreviated terms
The abbreviations defined in DSP0004, DSP0223, and DSP1001 apply to this document. The
following additional abbreviations are used in this document.
4.1
CIM
Common Information Model
4.2
IP
Internet Protocol
4.3
OVF
Open Virtualization Format
4.4
VS
virtual system
4.5
VSC
virtual system collection
5 OVF package
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. See D.1 for an example.
An OVF package can be stored as either a single compressed file (.ova) 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 digests of individual files in the
package. OVF packages authored according to this version of the specification shall use SHA256
digests. 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 should
verify the digests in the manifest file in the OVF package by computing the actual SHA digests and
comparing them with the digests listed in the manifest file. The manifest file shall contain SHA digests
for all distinct files referenced in the References element of the OVF descriptor and for no other files.
See 7.1
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 )
© ISO/IEC 2017 – All rights reserved 5

INCITS 469-2015
file_digest  = algorithm "(" file_name ")" "=" sp digest nl
algorithm   = "SHA1" | "SHA256"
digest    = *( hex-digit )
hex-digit   = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" |
"b" | "c" | "d" | "e" | "f"
sp      = %x20
nl      = %x0A
See D.1 for an example.
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.
See ANNEX F for deployment considerations.
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" | "SHA256"
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
See D.1 for an example.
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 that 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. The URI should be resolvable.
5.3 OVF package options
An OVF package may be stored as a compressed OVF package or as a set of files in a directory
structure. A compressed OVF package is stored as single file. The file extension is .ova (open virtual
appliance or application). See D.2 for an example.
All file references in the OVF descriptor are relative-path references and are described in section 7.1.
Entries in a compressed OVF package shall exist only once.
6    © ISO/IEC 2017 – All rights reserved

INCITS 469-2015
In addition, the entries shall be in one of the following orders inside the OVF package:
1) OVF descriptor
2) 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).
or
1) OVF descriptor
2) OVF manifest
3) OVF certificate
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).
or
1) OVF descriptor
2) The intermediate 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).
3) OVF manifest
4) OVF certificate
The ordering restriction ensures that it is possible to extract the OVF descriptor from a compressed
OVF package without scanning the entire archive. The ordering restriction enables the efficient
generation of a compressed OVF package-
A compressed OVF package shall be created by using the TAR format that complies with the USTAR
(Uniform Standard Tape Archive) format as defined by the ISO/IEC/IEEE 9945:2009.
5.4 Distribution as a set of files
An OVF package may be made available as a set of files. See D.2 for an example.
6 OVF descriptor
The OVF descriptor contains the metadata about the OVF package. This is an extensible XML
document for encoding information, such as product details, virtual hardware requirements, and
licensing.
DSP8023 is the schema definition file for the OVF descriptor that contains the elements and
attributes. The OVF descriptor shall validate against DSP8023.
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 namespaces used in this specification are listed in Table 1. The choice of any namespace
prefix is arbitrary and not semantically significant.
© ISO/IEC 2017 – All rights reserved 7

INCITS 469-2015
Table 1 – XML namespace prefixes
Prefix XML Namespace
ovf http://schemas.dmtf.org/ovf/envelope/2
ovfenv http://schemas.dmtf.org/ovf/environment/1
rasd http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/
CIM_ResourceAllocationSettingData.xsd
vssd http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/
CIM_VirtualSystemSettingData.xsd
epasd http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/
CIM_EthernetPortAllocationSettingData.xsd
sasd http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/
CIM_StorageAllocationSettingData.xsd
cim http://schemas.dmtf.org/wbem/wscim/1/common.xsd
7 Envelope element
The Envelope element describes all metadata for the virtual systems (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, e.g., virtual disk files, ISO images, and
internationalization resources
 A metadata part, defined by section elements, defined in clause 9
 A description of the content, either a single virtual system (VirtualSystem element) or a
collection of multiple virtual systems (VirtualSystemCollection element)
 A specification of message resource bundles for zero or more locales, defined by a Strings
element for each locale
See D.3 for an example.
The xml:lang attribute on the Envelope element is optional. If present, it shall specify the default
locale for messages in the descriptor. The Strings element is optional. If present, it shall contain
string resource bundles for different locales. See clause 10 for more details about internationalization
support.
7.1 File references
The file reference part defined by the References element allows a tool to 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). Relative path
references shall not contain “.” dot-segments. 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 relative to the location of the OVF descriptor itself. The relative path name shall use the
8    © ISO/IEC 2017 – All rights reserved

INCITS 469-2015
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
shall be bytes. If present, the value of the ovf:size attribute should 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, 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
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 attribute shall be the size of each chunk, except the last chunk, which
may be smaller.
If the ovf:chunkSize attribute 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 shall be as follows:
chunk-url   = href-value "." chunk-number
chunk-number = 9(decimal-digit)
decimal-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
The syntax is defined in ABNF notation with the exceptions listed in ANNEX A. The href-value shall be
the value of the ovf:href attribute. The chunk-number shall be the 0-based position of the chunk
starting with the value 0 and increasing with increments of 1 for each chunk.
If chunking is combined with compression, the entire file shall be 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. If
chunked files are used, the manifest file may contain an entry for the entire file; and if present, this
digest shall also be verified. See D.4 for an example.
7.2 Content element
Virtual system 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 Schema, the VirtualSystem and VirtualSystemCollection elements are part of a
substitution group with the Content element as head of the substitution group. The Content element
is abstract and cannot be used directly. The OVF descriptor shall have one or more Content
elements.
The VirtualSystem element describes a single virtual system and is a container of section elements.
These section elements describe virtual hardware, resources, and product information as defined in
clauses 8 and 9. See D.5 for an example.
The VirtualSystemCollection element is a container of zero or more VirtualSystem or
VirtualSystemCollection elements. Thus, arbitrary complex configurations can be described. The
section elements at the VirtualSystemCollection level describe appliance information, properties,
and resource requirements as defined in clause 9. See D.5 for an example.
© ISO/IEC 2017 – All rights reserved 9

INCITS 469-2015
All elements in the Content substitution group shall contain an Info element and may contain a Name
element. The Info element contains a human readable description of the meaning of this entity. The
Name element is a localizable display name of the content. Clause 10 defines how to localize the Info
and Name element.
7.3 Extensibility
Custom metadata may be added to OVF descriptors in several ways:
 New section elements may be defined as part of the Section substitution group, and used
Section element
where the OVF Schemas allow sections to be present. All subtypes of the
shall contain an Info element that contains a human-readable description of the meaning of
this entity. The values of Info elements can be used, for example, to give meaningful
warnings to users when a section is being skipped, even if the parser does not know
anything about the section. Clause 10 defines how to localize the Info element.
 The OVF Schemas use an open content model, where all existing types may be extended at
the end with additional elements. Extension points are declared in the OVF Schemas with
xs:any declarations with namespace="##other".
 The OVF Schemas allow additional attributes on existing types.
Custom extensions shall not use XML namespaces defined in this specification. This applies to both
custom elements and custom attributes.
If custom elements are used, the ovf:required attribute specifies whether the information in the
element is mandatory or is optional. If not specified, the ovf:required attribute defaults to TRUE,
i.e., mandatory. A deployment function that detects a custom element that is mandatory and that it
does not understand shall fail.
If custom attributes are used, the information contained in them shall not be required for correct
behavior.
If a Section element defined in the OVF Schema is used and it contains additional child elements
ovf:required attribute is TRUE, the deployment
that are not understood and the value of their
function shall fail.
See D.6 for an example.
7.4 Conformance
This standard defines three conformance levels for OVF descriptors, with 1 being the highest level of
conformance:
 Conformance Level: 1 - The OVF descriptor uses only sections and elements and attributes
that are defined in this specification.
 Conformance Level: 2 - The OVF descriptor uses custom sections or elements or attributes
that are not defined in this specification and all such exte
...