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
Current Stage
9599 - Withdrawal of International Standard
Start Date
21-Sep-2017
Completion Date
21-Sep-2017
Ref Project

RELATIONS

Buy Standard

Standard
ISO/IEC 17203:2011 - Information technology -- Open Virtualization Format (OVF) specification
English language
37 pages
sale 15% off
Preview
sale 15% off
Preview

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 17203:2011(E)
ISO/IEC 2011
---------------------- Page: 1 ----------------------
ISO/IEC 17203:2011(E)
COPYRIGHT PROTECTED DOCUMENT
© 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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2011 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 17203:2011(E)
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
---------------------- Page: 3 ----------------------
INCITS 469-2010
for Information Technology –
Open Virtualization Format
(OVF) Specification
Developed by
INCITS 469-2010
American National Standard
---------------------- Page: 4 ----------------------
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.
---------------------- Page: 5 ----------------------
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
Copyright © 2010 by Information Technology Industry Council (ITI)
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
---------------------- Page: 6 ----------------------
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

---------------------- Page: 7 ----------------------
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

---------------------- Page: 8 ----------------------

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
---------------------- Page: 9 ----------------------
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.)
---------------------- Page: 10 ----------------------
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
---------------------- Page: 11 ----------------------
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
---------------------- Page: 12 ----------------------
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

---------------------- Page: 13 ----------------------
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.
3
---------------------- Page: 14 ----------------------
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
Internet Protocol
4.1.3
OVF
Open Virtualization Format
4.1.4
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

---------------------- Page: 15 ----------------------
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"
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.