Open Virtualization Format Specification: Document Number: DSP0243 Date: 2010-01-12

1
2 Document Number: DSP0243
3 Date: 2010-01-12
4 Version: 1.1.0
5 Open Virtualization Format Specification
6 Document Type: Specification
7 Document Status: DMTF Standard
8 Document Language: E
Open Virtualization Format Specification DSP0243
9 Copyright notice
10 Copyright © 2010 Distributed Management Task Force, Inc. (DMTF). All rights reserved.
11 DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems
12 management and interoperability. Members and non-members may reproduce DMTF specifications and
13 documents, provided that correct attribution is given. As DMTF specifications may be revised from time to
14 time, the particular version and release date should always be noted.
15 Implementation of certain elements of this standard or proposed standard may be subject to third party
16 patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations
17 to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose,
18 or identify any or all such third party patent right, owners or claimants, nor for any incomplete or
19 inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to
20 any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize,
21 disclose, or identify any such third party patent rights, or for such party’s reliance on the standard or
22 incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any
23 party implementing such standard, whether such implementation is foreseeable or not, nor to any patent
24 owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is
25 withdrawn or modified after publication, and shall be indemnified and held harmless by any party
26 implementing the standard from any and all claims of infringement by a patent owner for such
27 implementations.
28 For information about patents held by third-parties which have notified the DMTF that, in their opinion,
29 such patent may relate to or impact implementations of DMTF standards, visit
30 http://www.dmtf.org/about/policies/disclosures.php.
2 DMTF Standard Version 1.1.0

DSP0243 Open Virtualization Format Specification
31 CONTENTS
32 Foreword ....................................................................................................................................................... 5
33 Introduction ................................................................................................................................................... 6
34 1 Scope .................................................................................................................................................... 7
35 2 Normative References........................................................................................................................... 7
36 3 Terms and Definitions ........................................................................................................................... 8
37 4 Symbols and Abbreviated Terms ........................................................................................................ 10
38 5 OVF Packages .................................................................................................................................... 10
39 5.1 OVF Package Structure ............................................................................................................ 10
40 5.2 Virtual Disk Formats.................................................................................................................. 12
41 5.3 Distribution as a Single File ...................................................................................................... 12
42 5.4 Distribution as a Set of Files ..................................................................................................... 13
43 6 OVF Descriptor.................................................................................................................................... 13
44 7 Envelope Element ............................................................................................................................... 14
45 7.1 File References......................................................................................................................... 15
46 7.2 Content Element ....................................................................................................................... 16
47 7.3 Extensibility ............................................................................................................................... 17
48 7.4 Conformance ............................................................................................................................ 18
49 8 Virtual Hardware Description............................................................................................................... 19
50 8.1 VirtualHardwareSection ............................................................................................................ 19
51 8.2 Extensibility ............................................................................................................................... 20
52 8.3 Virtual Hardware Elements ....................................................................................................... 20
53 8.4 Ranges on Elements................................................................................................................. 22
54 9 Core Metadata Sections...................................................................................................................... 24
55 9.1 DiskSection ............................................................................................................................... 25
56 9.2 NetworkSection......................................................................................................................... 26
57 9.3 ResourceAllocationSection....................................................................................................... 26
58 9.4 AnnotationSection..................................................................................................................... 27
59 9.5 ProductSection.......................................................................................................................... 27
60 9.6 EulaSection............................................................................................................................... 30
61 9.7 StartupSection .......................................................................................................................... 31
62 9.8 DeploymentOptionSection ........................................................................................................ 32
63 9.9 OperatingSystemSection .......................................................................................................... 34
64 9.10 InstallSection............................................................................................................................. 34
65 10 Internationalization .............................................................................................................................. 34
66 11 OVF Environment................................................................................................................................ 36
67 11.1 Environment Document ............................................................................................................ 36
68 11.2 Transport................................................................................................................................... 38
69 ANNEX A (informative) Symbols and Conventions ................................................................................... 39
70 ANNEX B (informative) Change Log.......................................................................................................... 40
71 ANNEX C (normative) OVF XSD ............................................................................................................... 41
72 Bibliography ................................................................................................................................................ 42
73
Version 1.1.0 DMTF Standard 3

74 Tables
75 Table 1 – XML Namespace Prefixes .......................................................................................................... 13
76 Table 2 – Actions for Child Elements with ovf:required Attribute......................................................... 20
77 Table 3 – HostResource Element ............................................................................................................... 21
78 Table 4 – Elements for Virtual Devices and Controllers ............................................................................. 22
79 Table 5 – Core Metadata Sections ............................................................................................................. 24
80 Table 6 – Property Types............................................................................................................................ 30
81 Table 7 – Property Qualifiers ...................................................................................................................... 30
82 Table 8 – Core Sections.............................................................................................................................. 38
83

84 Foreword
85 The Open Virtualization Format Specification (DSP0243) was prepared by the System Virtualization,
86 Partitioning, and Clustering Working Group of the DMTF.
87 This specification has been developed as a result of joint work with many individuals and teams,
88 including:
89 Simon Crosby, XenSource
90 Ron Doyle, IBM
91 Mike Gering, IBM
92 Michael Gionfriddo, Sun Microsystems
93 Steffen Grarup, VMware (Co-Editor)
94 Steve Hand, Symantec
95 Mark Hapner, Sun Microsystems
96 Daniel Hiltgen, VMware
97 Michael Johanssen, IBM
98 Lawrence J. Lamers, VMware (Chair)
99 John Leung, Intel Corporation
100 Fumio Machida, NEC Corporation
101 Andreas Maier, IBM
102 Ewan Mellor, XenSource
103 John Parchem, Microsoft
104 Shishir Pardikar, XenSource
105 Stephen J. Schmidt, IBM
106 René W. Schmidt, VMware (Co-Editor)
107 Andrew Warfield, XenSource
108 Mark D. Weitzel, IBM
109 John Wilson, Dell

110 Introduction
111 The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and
112 extensible format for the packaging and distribution of software to be run in virtual machines. The key
113 properties of the format are as follows:
114 • Optimized for distribution
115 OVF supports content verification and integrity checking based on industry-standard public key
116 infrastructure, and it provides a basic scheme for management of software licensing.
117 • Optimized for a simple, automated user experience
118 OVF supports validation of the entire package and each virtual machine or metadata
119 component of the OVF during the installation phases of the virtual machine (VM) lifecycle
120 management process. It also packages with the package relevant user-readable descriptive
121 information that a virtualization platform can use to streamline the installation experience.
122 • Supports both single VM and multiple-VM configurations
123 OVF supports both standard single VM packages and packages containing complex, multi-tier
124 services consisting of multiple interdependent VMs.
125 • Portable VM packaging
126 OVF is virtualization platform neutral, while also enabling platform-specific enhancements to be
127 captured. It supports the full range of virtual hard disk formats used for hypervisors today, and it
128 is extensible, which allow it to accommodate formats that may arise in the future. Virtual
129 machine properties are captured concisely and accurately.
130 • Vendor and platform independent
131 OVF does not rely on the use of a specific host platform, virtualization platform, or guest
132 operating system.
133 • Extensible
134 OVF is immediately useful — and extensible. It is designed to be extended as the industry
135 moves forward with virtual appliance technology. It also supports and permits the encoding of
136 vendor-specific metadata to support specific vertical markets.
137 • Localizable
138 OVF supports user-visible descriptions in multiple locales, and it supports localization of the
139 interactive processes during installation of an appliance. This capability allows a single
140 packaged appliance to serve multiple market opportunities.
141 • Open standard
142 OVF has arisen from the collaboration of key vendors in the industry, and it is developed in an
143 accepted industry forum as a future standard for portable virtual machines.
144 It is not an explicit goal for OVF to be an efficient execution format. A hypervisor is allowed but not
145 required to run software in virtual machines directly out of the Open Virtualization Format.
146

147 Open Virtualization Format Specification
148 1 Scope
149 The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and
150 extensible format for the packaging and distribution of software to be run in virtual machines.
151 2 Normative References

152 The following referenced documents are indispensable for the application of this document. For dated
153 references, only the edition cited applies. For undated references, the latest edition of the referenced
154 document (including any amendments) applies.
155 ANSI/IEEE Standard 1003.1-2008, IEEE Standard for Information Technology- Portable Operating
156 System Interface (POSIX) Base Specifications, Issue 7, Institute of Electrical and Electronics Engineers,
157 December 2008, http://standards.ieee.org/index.html
158 DMTF CIM Schema 2.22,

159 http://www.dmtf.org/standards/cim
160 DMTF DSP0004, Common Information Model (CIM) Infrastructure Specification 2.5,
161 http://www.dmtf.org/standards/published_documents/DSP0004_2.5.pdf
162 DMTF DSP0230, WS-CIM Mapping Specification 1.0,

164 DMTF DSP1041, Resource Allocation Profile (RAP) 1.1,

166 DMTF DSP1043, Allocation Capabilities Profile (ACP) 1.0,

168 IETF RFC 1738, T. Berners-Lee, Uniform Resource Locators (URL), December 1994,
169 http://www.ietf.org/rfc/rfc1738.txt
170 IETF RFC 1952, P. Deutsch, GZIP file format specification version 4.3, May 1996,
172 IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF,
174 IETF RFC 2616, R. Fielding et al, Hypertext Transfer Protocol – HTTP/1.1, June 1999,
176 IETF RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax,
178 ISO 9660, 1988 Information processing-Volume and file structure of CD-ROM for information interchange,
179 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=17505
180 ISO, ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards,
181 http://isotc.iso.org/livelink/livelink.exe?func=ll&objId=4230456&objAction=browse&sort=subtype

182 3 Terms and Definitions

183 For the purposes of this document, the following terms and definitions apply.
184 3.1
185 can
186 used for statements of possibility and capability, whether material, physical, or causal
187 3.2
188 cannot
189 used for statements of possibility and capability, whether material, physical, or causal
190 3.3
191 conditional
192 indicates requirements to be followed strictly to conform to the document when the specified conditions
193 are met
194 3.4
195 mandatory
196 indicates requirements to be followed strictly to conform to the document and from which no deviation is
197 permitted
198 3.5
199 may
200 indicates a course of action permissible within the limits of the document
201 3.6
202 need not
204 3.7
205 optional
207 3.8
208 shall
210 permitted
211 3.9
212 shall not
214 permitted
215 3.10
216 should
217 indicates that among several possibilities, one is recommended as particularly suitable, without
218 mentioning or excluding others, or that a certain course of action is preferred but not necessarily required
219 3.11
220 should not
221 indicates that a certain possibility or course of action is deprecated but not prohibited

222 3.12
223 appliance
224 see virtual appliance
225 3.13
226 deployment platform
227 the product that installs an OVF package
228 3.14
229 guest software
230 the software, stored on the virtual disks, that runs when a virtual machine is powered on
231 The guest is typically an operating system and some user-level applications and services.
232 3.15
233 OVF package
234 OVF XML descriptor file accompanied by zero or more files
235 3.16
236 OVF descriptor
237 OVF XML descriptor file
238 3.17
239 platform
240 see deployment platform
241 3.18
242 virtual appliance
243 a service delivered as a complete software stack installed on one or more virtual machines
244 A virtual appliance is typically expected to be delivered in an OVF package.
245 3.19
246 virtual hardware
247 the hardware (including the CPU, controllers, Ethernet devices, and disks) that is seen by the guest
248 software
249 3.20
250 virtual machine
251 the complete environment that supports the execution of guest software
252 A virtual machine is a full encapsulation of the virtual hardware, virtual disks, and the metadata
253 associated with it. Virtual machines allow multiplexing of the underlying physical machine through a
254 software layer called a hypervisor.
255 3.21
256 virtual machine collection
257 a service comprised of a set of virtual machines
258 The service can be a simple set of one or more virtual machines, or it can be a complex service built out
259 of a combination of virtual machines and other virtual machine collections. Because virtual machine
260 collections can be composed, it enables complex nested components.

261 4 Symbols and Abbreviated Terms

262 The following symbols and abbreviations are used in this document.
263 4.1.1
264 CIM
265 Common Information Model
266 4.1.2
267 IP
268 Internet Protocol
269 4.1.3
270 OVF
271 Open Virtualization Format
272 4.1.4
273 VM
274 Virtual Machine
275 5 OVF Packages

276 5.1 OVF Package Structure
277 An OVF package shall consist of the following files:
278 • one OVF descriptor with extension .ovf
279 • zero or one OVF manifest with extension .mf
280 • zero or one OVF certificate with extension .cert
281 • zero or more disk image files
282 • zero or more additional resource files, such as ISO images
283 The file extensions .ovf, .mf and .cert shall be used.
284 EXAMPLE 1: The following list of files is an example of an OVF package:
285 package.ovf
286 package.mf
287 de-DE-resources.xml
288 vmdisk1.vmdk
289 vmdisk2.vmdk
290 resource.iso
291 NOTE: The previous example uses VMDK disk files, but multiple disk formats are supported.
292 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
293 modes shall be supported.
294 An OVF package may have a manifest file containing the SHA-1 digests of individual files in the
295 package. The manifest file shall have an extension .mf and the same base name as the .ovf file and be
296 a sibling of the .ovf file. If the manifest file is present, a consumer of the OVF package shall verify the

297 digests by computing the actual SHA-1 digests and comparing them with the digests listed in the manifest
298 file.
299 The syntax definitions below use ABNF with the exceptions listed in ANNEX A.
300 The format of the manifest file is as follows:

301 manifest_file = *( file_digest )
302 file_digest = algorithm "(" file_name ")" "=" sp digest nl
303 algorithm = "SHA1"
304 digest = 40( hex-digit ) ; 160-bit digest in 40-digit hexadecimal
305 hex-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" |
306 "b" | "c" | "d" | "e" | "f"
307 sp = %x20
308 nl = %x0A
309 EXAMPLE 2: The following example show the partial contents of a manifest file:
310 SHA1(package.ovf)= 237de026fb285b85528901da058475e56034da95
311 SHA1(vmdisk1.vmdk)= 393a66df214e192ffbfedb78528b5be75cc9e1c3
312 An OVF package may be signed by signing the manifest file. The digest of the manifest file is stored in a
313 certificate file with extension .cert file along with the base64-encoded X.509 certificate. The .cert file
314 shall have the same base name as the .ovf file and be a sibling of the .ovf file. A consumer of the OVF
315 package shall verify the signature and should validate the certificate. The format of the certificate file shall
316 be as follows:
317 certificate_file =
manifest_digest certificate_part
318 manifest_digest =
algorithm "(" file_name ")" "=" sp signed_digest nl
319 algorithm =
"SHA1"
320 signed_digest =
*( hex-digit)
321 certificate_part =
certificate_header certificate_body certificate_footer
322 certificate_header =
"-----BEGIN CERTIFICATE-----" nl
323 certificate_footer =
"-----END CERTIFICATE-----" nl
324 certificate_body =
base64-encoded-certificate nl
325 ; base64-encoded-certificate is a base64-encoded X.509
326 ; certificate, which may be split across multiple lines
327 hex-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a"
328 | "b" | "c" | "d" | "e" | "f"
329 sp = %x20
330 nl = %x0A
331 EXAMPLE 3: The following list of files is an example of a signed OVF package:
332 package.ovf
333 package.mf
334 package.cert
335 de-DE-resources.xml
336 vmdisk1.vmdk
337 vmdisk2.vmdk
338 resource.iso
339 EXAMPLE 4: The following example shows the contents of a sample OVF certification file, where the SHA1 digest
340 of the manifest file has been signed with a 512 bit key:
341 SHA1(package.mf)= 7f4b8efb8fe20c06df1db68281a63f1b088e19dbf00e5af9db5e8e3e319de
342 7019db88a3bc699bab6ccd9e09171e21e88ee20b5255cec3fc28350613b2c529089

343 -----BEGIN CERTIFICATE-----

344 MIIBgjCCASwCAQQwDQYJKoZIhvcNAQEEBQAwODELMAkGA1UEBhMCQVUxDDAKBgNV
345 BAgTA1FMRDEbMBkGA1UEAxMSU1NMZWF5L3JzYSB0ZXN0IENBMB4XDTk1MTAwOTIz
346 MzIwNVoXDTk4MDcwNTIzMzIwNVowYDELMAkGA1UEBhMCQVUxDDAKBgNVBAgTA1FM
347 RDEZMBcGA1UEChMQTWluY29tIFB0eS4gTHRkLjELMAkGA1UECxMCQ1MxGzAZBgNV
348 BAMTElNTTGVheSBkZW1vIHNlcnZlcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC3
349 LCXcScWua0PFLkHBLm2VejqpA1F4RQ8q0VjRiPafjx/Z/aWH3ipdMVvuJGa/wFXb
350 /nDFLDlfWp+oCPwhBtVPAgMBAAEwDQYJKoZIhvcNAQEEBQADQQArNFsihWIjBzb0
351 DcsU0BvL2bvSwJrPEqFlkDq3F4M6EgutL9axEcANWgbbEdAvNJD1dmEmoWny27Pn
352 Ims6ZOZB
353 -----END CERTIFICATE-----
354 The manifest and certificate files, when present, shall not be included in the References section of the
355 OVF descriptor (see 7.1). This ensures that the OVF descriptor content does not depend on whether the
356 OVF package has a manifest or is signed, and the decision to add a manifest or certificate to a package
357 can be deferred to a later stage.
358 The file extensions .mf and .cert may be used for other files in an OVF package, as long as they do
359 not occupy the sibling URLs or path names where they would be interpreted as the package manifest or
360 certificate.
361 5.2 Virtual Disk Formats

362 OVF does not require any specific disk format to be used, but to comply with this specification the disk
363 format shall be given by a URI which identifies an unencumbered specification on how to interpret the
364 disk format. The specification need not be machine readable, but it shall be static and unique so that the
365 URI may be used as a key by software reading an OVF package to uniquely determine the format of the
366 disk. The specification shall provide sufficient information so that a skilled person can properly interpret
367 the disk format for both reading and writing of disk data. It is recommended that these URIs are
368 resolvable.
369 5.3 Distribution as a Single File

370 An OVF package may be stored as a single file using the TAR format. The extension of that file shall be
371 .ova (open virtual appliance or application).
372 EXAMPLE: The following example shows a sample filename for an OVF package of this type:
373 D:\virtualappliances\myapp.ova
374 For OVF packages stored as single file, all file references in the OVF descriptor shall be relative-path
375 references and shall point to files included in the TAR archive. Relative directories inside the archive are
376 allowed, but relative-path references shall not contain “..” dot-segments.
377 Ordinarily, a TAR extraction tool would have to scan the whole archive, even if the file requested is found
378 at the beginning, because replacement files can be appended without modifying the rest of the archive.
379 For OVF TAR files, duplication is not allowed within the archive. In addition, the files shall be in the
380 following order inside the archive:
381 1) OVF descriptor
382 2) OVF manifest (optional)
383 3) OVF certificate (optional)
384 4) The remaining files shall be in the same order as listed in the References section (see 7.1).
385 Note that any external string resource bundle files for internationalization shall be first in the
386 References section (see clause 10).

387 5) OVF manifest (optional)

388 6) OVF certificate (optional)
389 Note that the certificate file is optional. If no certificate file is present, the manifest file is also optional. If
390 the manifest or certificate files are present, they shall either both be placed after the OVF descriptor, or
391 both be placed at the end of the archive.
392 For deployment, the ordering restriction ensures that it is possible to extract the OVF descriptor from an
393 OVF TAR file without scanning the entire archive. For generation, the ordering restriction ensures that an
394 OVF TAR file can easily be generated on-the-fly. The restrictions do not prevent OVF TAR files from
395 being created using standard TAR packaging tools.
396 The TAR format used shall comply with the USTAR (Uniform Standard Tape Archive) format as defined
397 by the POSIX IEEE 1003.1 standards group.
398 5.4 Distribution as a Set of Files

399 An OVF package can be made available as a set of files, for example on a standard Web server.
400 EXAMPLE: An example of an OVF package as a set of files on Web server follows:
401 http://mywebsite/virtualappliances/package.ovf
402 http://mywebsite/virtualappliances/vmdisk1.vmdk
403 http://mywebsite/virtualappliances/vmdisk2.vmdk
404 http://mywebsite/virtualappliances/resource.iso
405 http://mywebsite/virtualappliances/de-DE-resources.xml
406 6 OVF Descriptor

407 All metadata about the package and its contents is stored in the OVF descriptor. This is an extensible
408 XML document for encoding information, such as product details, virtual hardware requirements, and
409 licensing.
410 The dsp8023_1.1.0.xsd XML schema definition file for the OVF descriptor contains the elements and
411 attributes.
412 Clauses 7, 8, and 9, describe the semantics, structure, and extensibility framework of the OVF descriptor.
413 These clauses are not a replacement for reading the schema definitions, but they complement the
414 schema definitions.
415 The XML document of an OVF descriptor shall contain one Envelope element, which is the only element
416 allowed at the top level.
417 The XML namespaces used in this specification are listed in Table 1. The choice of any namespace prefix
418 is arbitrary and not semantically significant.
419 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
420 7 Envelope Element

421 The Envelope element describes all metadata for the virtual machines (including virtual hardware), as
422 well as the structure of the OVF package itself.
423 The outermost level of the envelope consists of the following parts:
424 • A version indication, defined by the XML namespace URIs.
425 • A list of file references to all external files that are part of the OVF package, defined by the
426 References element and its File child elements. These are typically virtual disk files, ISO
427 images, and internationalization resources.
428 • A metadata part, defined by section elements, as defined in clause 9.
429 • A description of the content, either a single virtual machine (VirtualSystem element) or a
430 collection of multiple virtual machines (VirtualSystemCollection element).
431 • A specification of message resource bundles for zero or more locales, defined by a Strings
432 element for each locale.
433 EXAMPLE: An example of the structure of an OVF descriptor with the top-level Envelope element follows:
434 <?xml version="1.0" encoding="UTF-8"?>
435 <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
436 xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-
437 schema/2/CIM_VirtualSystemSettingData"
438 xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-
439 schema/2/CIM_ResourceAllocationSettingData"
440 xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
441 xmlns="http://schemas.dmtf.org/ovf/envelope/1"
442 xml:lang="en-US">
443 <References>
444 <File ovf:id="de-DE-resources.xml" ovf:size="15240"
445 ovf:href="http://mywebsite/virtualappliances/de-DE-resources.xml"/>
446 <File ovf:id="file1" ovf:href="vmdisk1.vmdk" ovf:size="180114671"/>
447 <File ovf:id="file2" ovf:href="vmdisk2.vmdk" ovf:size="4882023564"
448 ovf:chunkSize="2147483648"/>
449 <File ovf:id="file3" ovf:href="resource.iso" ovf:size="212148764"
450 ovf:compression="gzip"/>
451 <File ovf:id="icon" ovf:href="icon.png" ovf:size="1360"/>
452 </References>
453 
454 <DiskSection>
455 <Info>Describes the set of virtual disks</Info>
456 
457 </DiskSection>
458 
459 <NetworkSection>
460 <Info>List of logical networks used in the package</Info>
462 </NetworkSection>
463 <SomeSection ovf:required="false">
464 <Info>A plain-text description of the content</Info>

466 </SomeSection>
467 
468 <VirtualSystemCollection ovf:id="Some Product">
469 
470 </VirtualSystemCollection >
471 <Strings xml:lang="de-DE">
472 
473 </Strings>
474 </Envelope>
475 The optional xml:lang attribute on the Envelope element shall specify the default locale for messages
476 in the descriptor. The optional Strings elements shall contain string resource bundles for different
477 locales. See clause 10 for more details on internationalization support.
478 7.1 File References

479 The file reference part defined by the References element allows a tool to easily determine the integrity
480 of an OVF package without having to parse or interpret the entire structure of the descriptor. Tools can
481 safely manipulate (for example, copy or archive) OVF packages with no risk of losing files.
482 External string resource bundle files for internationalization shall be placed first in the References
483 element, see clause 10 for details.
484 Each File element in the reference part shall be given an identifier using the ovf:id attribute. The
485 identifier shall be unique inside an OVF package. Each File element shall be specified using the
486 ovf:href attribute, which shall contain a URL. Relative-path references and the URL schemes "file",
487 "http", and "https" shall be supported, see RFC1738 and RFC3986. Other URL schemes should not
488 be used. If no URL scheme is specified, the value of the ovf:href attribute shall be interpreted as a
489 path name of the referenced file that is relative to the location of the OVF descriptor itself. The relative
490 path name shall use the syntax of relative-path references in RFC3986. The referenced file shall exist.
491 Two different File elements shall not reference the same file with their ovf:href attributes.
492 The size of the referenced file may be specified using the ovf:size attribute. The unit of this attribute is
493 always bytes. If present, the value of the ovf:size attribute shall match the actual size of the referenced
494 file.
495 Each file referenced by a File element may be compressed using gzip (see RFC1952). When a File
496 element is compressed using gzip, the ovf:compression attribute shall be set to “gzip”. Otherwise,
497 the ovf:compression attribute shall be set to “identity” or the entire attribute omitted. Alternatively,
498 if the href is an HTTP or HTTPS URL, then the compression may be specified by the HTTP server by
499 using the HTTP header Content-Encoding: gzip (see RFC2616). Using HTTP content encoding in
500 combination with the ovf:compression attribute is allowed, but in general does not improve the
501 compression ratio. When compression is used, the ovf:size attribute shall specify the size of the actual
502 compressed file.
503 Files referenced from the reference part may be split into chunks to accommodate file size restrictions on
504 certain file systems. Chunking shall be indicated by the presence of the ovf:chunkSize attribute; the
505 value of ovf:chunkSize shall be the size of each chunk, except the last chunk, which may be smaller.
506 When ovf:chunkSize is specified, the File element shall reference a chunk file representing a chunk
507 of the entire file. In this case, the value of the ovf:href attribute specifies only a part of the URL, and
508 the syntax for the URL resolving to the chunk file is as follows. The syntax uses ABNF with the exceptions
509 listed in ANNEX A.
510 chunk-url = href-value "." chunk-number
511 chunk-number = 9(decimal-digit)

512 decimal-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
513 In this syntax, href-value is the value of the ovf:href attribute, and chunk-number is the 0-based
514 position of the chunk starting with the value 0 and increases with increments of 1 for each chunk.
515 Chunking can be combined with compression, the entire file is then compressed before chunking and
516 each chunk shall be an equal slice of the compressed file, except for the last chunk which may be
517 smaller.
518 If the OVF package has a manifest file, the file name in the manifest entries shall match the value of the
519 ovf:href attribute for the file, except if the file is split into multiple chunks, in which case the chunk-
520 url shall be used, and the manifest file shall contain an entry for each individual chunk. For chunked
521 files, the manifest file is allowed to contain an entry for the entire file; if present this digest shall also be
522 verified.
523 EXAMPLE 1: The following example shows different types of file references:
524 <File ovf:id="disk1" ovf:href="disk1.vmdk"/>
525 <File ovf:id="disk2" ovf:href="disk2.vmdk" ovf:size="5368709120"
526 ovf:chunkSize="2147483648"/>
527 <File ovf:id="iso1" ovf:href="resources/image1.iso"/>
528 <File ovf:id="iso2" ovf:href="http://mywebsite/resources/image2.iso"/>
529 EXAMPLE 2: The following example shows manifest entries corresponding to the file references above:
530 SHA1(disk1.vmdk)= 3e19644ec2e806f38951789c76f43e4a0ec7e233
531 SHA1(disk2.vmdk.000000000)= 4f7158731ff434380bf217da248d47a2478e79d8
532 SHA1(disk2.vmdk.000000001)= 12849daeeaf43e7a89550384d26bd437bb8defaf
533 SHA1(disk2.vmdk.000000002)= 4cdd21424bd9eeafa4c42112876217de2ee5556d
534 SHA1(resources/image1.iso)= 72b37ff3fdd09f2a93f1b8395654649b6d06b5b3
535 SHA1(http://mywebsite/resources/image2.iso)=
536 d3c2d179011c970615c5cf10b30957d1c4c968ad
537 7.2 Content Element

538 Virtual machine configurations in an OVF package are represented by a VirtualSystem or
539 VirtualSystemCollection element. These elements shall be given an identifier using the ovf:id
540 attribute. Direct child elements of a VirtualSystemCollection shall have unique identifiers.
541 In the OVF schema, the VirtualSystem and VirtualSystemCollection elements are part of a
542 substitution group with the Content element as head of the substitution group. The Content element is
543 abstract and cannot be used directly. The OVF descriptor shall have one or more Content elements.
544 The VirtualSystem element describes a single virtual machine and is simply a container of section
545 elements. These section elements describe virtual hardware, resources, and product information and are
546 described in detail in clauses 8 and 9.
547 The structure of a VirtualSystem element is as follows:

548 <VirtualSystem ovf:id="simple-app">
549 <Info>A virtual machine</Info>
550 <Name>Simple Appliance</Name>
551 <SomeSection>
553 </SomeSection>
555 </VirtualSystem>
556 The VirtualSystemCollection element is a container of multiple VirtualSystem or

557 VirtualSystemCollection elements. Thus, arbitrary complex configurations can be described. The

558 section elements at the VirtualSystemCollection level describe appliance information, properties,
559 resource requirements, and so on, and are described in detail in clause 9.
560 The structure of a VirtualSystemCollection element is as follows:

561 <VirtualSystemCollection ovf:id="multi-tier-app">
562 <Info>A collection of virtual machines</Info>
563 <Name>Multi-tiered Appliance</Name>
564 <SomeSection>
566 </SomeSection>
568 <VirtualSystem ovf:id="...">
569 
570 </VirtualSystem>
571 
572 </VirtualSystemCollection>
573 All elements in the Content substitution group shall contain an Info element and may contain a Name
574 element. The Info element contains a human readable description of the meaning of this entity. The
575 Name element is an optional localizable display name of the content. See clause 10 for details on how to
576 localize the Info and Name element.
577 7.3 Extensibility

578 This specification allows custom meta-data to be added to OVF descriptors in several ways:
579 • New section elements may be defined as part of the Section substitution group, and used
580 where the OVF schemas allow sections to be present. All subtypes of Section contain an Info
581 element that contains a human readable description of the meaning of this entity. The values of
582 Info elements can be used, for example, to give meaningful warnings to users when a section is
583 being skipped, even if the parser does not know anything about the section. See clause 10 for
584 details on how to localize the Info element.
585 • The OVF schemas use an open content model, where all existing types may be extended at the
586 end with additional elements. Extension points are declared in the OVF schemas with xs:any
587 declarations with namespace="##other".
588 • The OVF schemas allow additional attributes on existing types.
589 Custom extensions shall not use XML namespaces defined in this specification. This applies to both
590 custom elements and custom attributes.
591 On custom elements, a Boolean ovf:required attribute specifies whether the information in the
592 element is required for correct behavior or optional. If not specified, the ovf:required attribute defaults
593 to TRUE. A consumer of an OVF package that detects an extension that is required and that it does not
594 understand shall fail.
595 For known Section elements, if additional child elements that are not understood are found and the
596 value of their ovf:required attribute is TRUE, the consumer of the OVF package shall interpret the
597 entire section as one it does not understand. The check is not recursive; it applies only to the direct
598 children of the Section element.
599 This behavior ensures that older parsers reject newer OVF specifications, unless explicitly instructed not
600 to do so.

601 On custom attributes, the information in the attribute shall not be required for correct behavior.
602 EXAMPLE 1:
603 <!—- Optional custom section example -->
604 <otherns:IncidentTrackingSection ovf:required="false">
605 <Info>Specifies information useful for incident tracking purposes</Info>
606 <BuildSystem>Acme Corporation Official Build System</BuildSystem>
607 <BuildNumber>102876</BuildNumber>
608 <BuildDate>10-10-2008</BuildDate>
609 </otherns:IncidentTrackingSection>
610 EXAMPLE 2:
611 <!—- Open content example (extension of existing type) -->
612 <AnnotationSection>
613 <Info>Specifies an annotation for this virtual machine</Info>
614 <Annotation>This is an example of how a future element (Author) can still be
615 parsed by older clients</Annotation>
616 
617 <otherns:Author ovf:required="false">John Smith</otherns:Author>
618 </AnnotationSection>
619 EXAMPLE 3:
620 <!—- Optional custom attribute example -->
621 <Network ovf:name="VM network" otherns:desiredCapacity="1 Gbit/s">
622 <Description>The main network for VMs</Description>
623 </Network>
624 7.4 Conformance

625 This specification defines three conformance levels for OVF descriptors, with 1 being the highest level of
626 conformance:
627 • OVF descriptor uses only sections and elements and attributes that are defined in this
628 specification.
629 Conformance Level: 1.
630 • OVF descriptor uses custom sections or elements or attributes that are not defined in this
631 specification, and all such extensions are optional as defined in 7.3.
633 • OVF descriptor uses custom sections or elements that are not defined in this specification and at
634 least one such extension is required as defined in 7.3. The definition of all required extensions
635 shall be publicly available in an open and unencumbered XML Schema. The complete
636 specification may be inclusive in the XML schema or available as a separate document.
638 The use of conformance level 3 limits portability and should be avoided if at all possible.
639 The conformance level is not specified directly in the OVF descriptor but shall be determined by the
640 above rules.

641 8 Virtual Hardware Description

642 8.1 VirtualHardwareSection
643 Each VirtualSystem element may contain one or more VirtualHardwareSection elements, each of which
644 describes the virtual hardware required by the virtual system.The virtual hardware required by a virtual
645 machine is specified in VirtualHardwareSection elements. This specification supports abstract or
646 incomplete hardware descriptions in which only the major devices are described. The hypervisor is
647 allowed to create additional virtual hardware controllers and devices, as long as the required devices
648 listed in the descriptor are realized.
649 This virtual hardware description is based on the CIM classes CIM_VirtualSystemSettingData and
650 CIM_ResourceAllocationSettingData. The XML representation of the CIM model is based on the
651 WS-CIM mapping (DSP0230).
652 EXAMPLE: Example of VirtualHardwareSection:
653 <VirtualHardwareSection ovf:id="minimal" ovf:transport="iso">
654 <Info>500Mb, 1 CPU, 1 disk, 1 nic virtual machine</Info>
655 <System>
656 <vssd:ElementName>Virtual System Type</vssd:ElementName>
657 <vssd:InstanceID>0</vssd:InstanceID>
658 <vssd:VirtualSystemType>vmx-4</vssd:VirtualSystemType>
659 </System>
660 <Item>
661 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits>
662 <rasd:Description>Memory Size</rasd:Description>
663 <rasd:ElementName>512 MB of memory</rasd:ElementName>
664 <rasd:InstanceID>2</rasd:InstanceID>
665 <rasd:ResourceType>4</rasd:ResourceType>
666 <rasd:VirtualQuantity>512</rasd:VirtualQuantity>
667 </Item>
668 
669 </VirtualHardwareSection>
670 A VirtualSystem element shall have a VirtualHardwareSection direct child element.

671 VirtualHardwareSection is disallowed as a direct child element of a VirtualSystemCollection
672 element and of an Envelope element.
673 Multiple VirtualHardwareSection element occurrences are allowed within a single VirtualSystem
674 element. The consumer of the OVF package should select the most appropriate virtual hardware
675 description for the particular virtualization platform. A VirtualHardwareSection element may contain
676 an ovf:id attribute which can be used to identify the element. If present the attribute value must be
677 unique within the VirtualSystem.
678 The ovf:transport attribute specifies the types of transport mechanisms by which properties are
679 passed to the virtual machine in an OVF environment document. This attribute supports a pluggable and
680 extensible architecture for providing guest/platform communication mechanisms. Several transport types
681 may be specified separated by single space character. See 9.5 for a description of properties and clause
682 11 for a description of transport types and OVF environments.
683 The vssd:VirtualSystemType element specifies a virtual system type identifier, which is an
684 implementation defined string that uniquely identifies the type of the virtual system. For example, a virtual
685 system type identifier could be vmx-4 for VMware’s fourth-generation virtual hardware or xen-3 for Xen’s

686 third-generation virtual hardware. Zero or more virtual system type identifiers may be specified separated
687 by single space character. In order for the OVF virtual system to be deployable on a target platform, the
688 virtual machine on the target platform is should support at least one of the virtual system types identified
689 in the vssd:VirtualSystemType elements. The virtual system type identifiers specified in
690 vssd:VirtualSystemType elements are expected to be matched against the values of property
691 VirtualSystemTypesSupported of CIM class CIM_VirtualSystemManagementCapabilities.
692 The virtual hardware characteristics are described as a sequence of Item elements. The Item element
693 is an XML representation of an instance of the CIM class CIM_ResourceAllocationSettingData.
694 The element can describe all memory and CPU requirements as well as virtual hardware devices.
695 Multiple device subtypes may be specified in an Item element, separated by a single space character.
696 EXAMPLE:
697 <rasd:ResourceSubType>buslogic lsilogic</rasd:ResourceSubType>
698 8.2 Extensibility

699 The optional ovf:required attribute on the Item element specifies whether the realization of the
700 element (for example, a CD-ROM or USB controller) is required for correct behavior of the guest software.
701 If not specified, ovf:required defaults to TRUE.
702 On child elements of the Item element, the optional Boolean attribute ovf:required shall be
703 interpreted, even though these elements are in a different RASD WS-CIM namespace. A tool parsing an
704 Item element should act according to Table 2.
705 Table 2 – Actions for Child Elements with ovf:required Attribute
Child Element ovf:required Attribute Value Action

Known TRUE or not specified Shall interpret Item
Known FALSE Shall interpret Item
Unknown TRUE or not specified Shall fail Item
Unknown FALSE Shall ignore Item
706 8.3 Virtual Hardware Elements

707 The general form of any Item element in a VirtualHardwareSection element is as follows:
708 <Item ovf:required="…" ovf:configuration="…" ovf:bound="…">
709 <rasd:Address> ... </rasd:Address>
710 <rasd:AddressOnParent> ... </rasd:AddressOnParent>
711 <rasd:AllocationUnits> ... </rasd:AllocationUnits>
712 <rasd:AutomaticAllocation> ... </rasd:AutomaticAllocation>
713 <rasd:AutomaticDeallocation> ... </rasd:AutomaticDeallocation>
714 <rasd:Caption> ... </rasd:Caption>
715 <rasd:Connection> ... </rasd:Connection>
716 
717 <rasd:ConsumerVisibility> ... </rasd:ConsumerVisibility>
718 <rasd:Description> ... </rasd:Description>
719 <rasd:ElementName> ... </rasd:ElementName>
720 <rasd:HostResource> ... </rasd:HostResource>
721 <rasd:InstanceID> ... </rasd:InstanceID>

722 <rasd:Limit> ... </rasd:Limit>

723 <rasd:MappingBehavior> ... </rasd:MappingBehavior>
724 <rasd:OtherResourceType> ... </rasd:OtherResourceType>
725 <rasd:Parent> ... </rasd:Parent>
726 <rasd:PoolID> ... </rasd:PoolID>
727 <rasd:Reservation> ... </rasd:Reservation>
728 <rasd:ResourceSubType> ... </rasd:ResourceSubType>
729 <rasd:ResourceType> ... </rasd:ResourceType>
730 <rasd:VirtualQuantity> ... </rasd:VirtualQuantity>
731 <rasd:Weight> ... </rasd:Weight>
732 </Item>
733 The elements represent the properties exposed by the CIM_ResourceAllocationSettingData

734 class. They have the semantics of defined settings as defined in DSP1041, any profiles derived from
735 DSP1041 for specific resource types, and this document.
736 EXAMPLE: The following example shows a description of memory size:
737 <Item>
739 <rasd:Description>Memory Size</rasd:Description>
740 <rasd:ElementName>256 MB of memory</rasd:ElementName>
744 </Item>
745 The Description element is used to provide additional metadata about the element itself. This element
746 enables a consumer of the OVF package to provide descriptive information about all items, including
747 items that were unknown at the time the application was written.
748 The Caption, Description and ElementName elements are localizable using the ovf:msgid
749 attribute from the OVF envelope namespace. See clause 10 for more details on internationalization
750 support.
751 The optional ovf:configuration attribute contains a list of configuration names. See 9.8 on
752 deployment options for semantics of this attribute. The optional ovf:bound attribute is used to specify
753 ranges; see 8.4.
754 Devices such as disks, CD-ROMs, and networks need a backing from the deployment platform. The
755 requirements on a backing are either specified using the HostResource or the Connection element.
756 For an Ethernet adapter, a logical network name is specified in the Connection element. Ethernet
757 adapters that refer to the same logical network name within an OVF package shall be deployed on the
758 same network.
759 The HostResource element is used to refer to resources included in the OVF descriptor as well as
760 logical devices on the deployment platform. Values for HostResource elements referring to resources
761 included in the OVF descriptor are formatted as URIs as specified in Table 3.
762 Table 3 – HostResource Element

Content Description
ovf:/file/<id> A reference to a file in the OVF, as specified in the References section. <id> shall be the
value of the ovf:id attribute of the File element being referenced.

ovf:/disk/<id> A reference to a virtual disk, as specified in the DiskSection. <id> shall be the value of
the ovf:diskId attribute of the Disk element being referenced.
763 If no backing is specified for a device that requires a backing, the deployment platform shall make an
764 appropriate choice, for example, by prompting the user. Specifying more than one backing for a device is
765 not allowed.
766 Table 4 gives a brief overview on how elements are used to describe virtual devices and controllers.
767 Table 4 – Elements for Virtual Devices and Controllers

Element Usage
rasd:Description A human-readable description of the meaning of the information. For example,
“Specifies the memory size of the virtual machine”.
rasd:ElementName A human-readable description of the content. For example, “256MB memory”.
rasd:InstanceID A unique instance ID of the element within the section.
rasd:HostResource Abstractly specifies how a device shall connect to a resource on the
deployment platform. Not all devices need a backing. See Table 3.
rasd:ResourceType Specifies the kind of device that is being described.
rasd:OtherResourceType
rasd:ResourceSubtype
rasd:AutomaticAllocation For devices that are connectable, such as floppies, CD-ROMs, and Ethernet
adaptors, this element specifies whether the device should be connected at
power on.
rasd:Parent The InstanceID of the parent controller (if any).
rasd:Connection For an Ethernet adapter, this specifies the abstract network connection name
for the virtual machine. All Ethernet adapters that specify the same abstract
network connection name within an OVF package shall be deployed on the
same network. The abstract network connection name shall be listed in the
NetworkSection at the outermost envelope level.
rasd:Address Device specific. For an Ethernet adapter, this specifies the MAC address.
rasd:AddressOnParent For a device, this specifies its location on the controller.
rasd:AllocationUnits Specifies the units of allocation used. For example, “byte * 2^20”.
rasd:VirtualQuantity Specifies the quantity of resources presented. For example, “256”.
rasd:Reservation Specifies the minimum quantity of resources guaranteed to be available.
rasd:Limit Specifies the maximum quantity of resources that are granted.
rasd:Weight Specifies a relative priority for this allocation in relation to other allocations.
768 Only fields directly related to describing devices are mentioned. Refer to the CIM MOF for a complete
769 description of all fields, each field corresponds to the identically named property in the
770 CIM_ResourceAllocationSettingData class.
771 8.4 Ranges on Elements

772 The optional ovf:bound attribute may be used to specify ranges for the Item elements. A range has a
773 minimum, normal, and maximum value, denoted by min, normal, and max, where min <= normal <=
774 max. The default values for min and max are those specified for normal.

775 A platform deploying an OVF package is recommended to start with the normal value and adjust the
776 value within the range for ongoing performance tuning and validation.
777 For the Item elements in VirtualHardwareSection and ResourceAllocationSection elements,

778 the following additional semantics are defined:
779 • Each Item element has an optional ovf:bound attribute. This value may be specified as min,
780 max, or normal. The value defaults to normal. If the attribute is not specified or is specified as
781 normal, then the item is interpreted as being part of the regular virtual hardware or resource
782 allocation description.
783 • If the ovf:bound value is specified as either min or max, the item is used to specify the upper
784 or lower bound for one or more values for a given InstanceID. Such an item is called a range
785 marker.
786 The semantics of range markers are as follows:

787 • InstanceID and ResourceType shall be specified, and the ResourceType shall match
788 other Item elements with the same InstanceID.
789 • Specifying more than one min range marker or more than one max range marker for a given
790 RASD (identified with InstanceID) is invalid.
791 • An Item element with a range marker shall have a corresponding Item element without a
792 range marker, that is, an Item element with no ovf:bound attribute or ovf:bound attribute
793 with value normal. This corresponding item specifies the default value.
794 • For an Item element where only a min range marker is specified, the max value is unbounded
795 upwards within the set of valid values for the property.
796 • For an Item where only a max range marker is specified, the min value is unbounded
797 downwards within the set of valid values for the property.
798 • The default value shall be inside the range.
799 • The use of non-integer elements in range marker RASDs is invalid.
800 EXAMPLE: The following example shows the use of range markers:
801 <VirtualHardwareSection>
802 <Info>...</Info>
803 <Item>
805 <rasd:ElementName>512 MB memory size</rasd:ElementName>
809 </Item>
810 <Item ovf:bound="min">
812 <rasd:ElementName>384 MB minimum memory size</rasd:ElementName>
814 <rasd:Reservation>384</rasd:Reservation>
816 </Item>
817 <Item ovf:bound="max">
819 <rasd:ElementName>1024 MB maximum memory size</rasd:ElementName>

823 </Item>
825 9 Core Metadata Sections

826 Table 5 shows the core metadata sections that are defined.
827 Table 5 – Core Metadata Sections

Section Locations Multiplicity
DiskSection Envelope Zero or one
Describes meta-information about all virtual disks in the
package
NetworkSection Envelope Zero or one
Describes logical networks used in the package
ResourceAllocationSection VirtualSystemCollection Zero or one
Specifies reservations, limits, and shares on a given resource,
such as memory or CPU for a virtual machine collection
AnnotationSection VirtualSystem Zero or one
Specifies a free-form annotation on an entity VirtualSystemCollection
ProductSection VirtualSystem Zero or more
Specifies product-information for a package, such as product VirtualSystemCollection
name and version, along with a set of properties that can be
configured
EulaSection VirtualSystem Zero or more
Specifies a license agreement for the software in the package VirtualSystemCollection
StartupSection VirtualSystemCollection Zero or one
Specifies how a virtual machine collection is powered on
DeploymentOptionSection Envelope Zero or one
Specifies a discrete set of intended resource requirements
OperatingSystemSection VirtualSystem Zero or one
Specifies the installed guest operating system of a virtual
machine
InstallSection VirtualSystem Zero or one
Specifies that the virtual machine needs to be initially booted
to install and configure the software
828 The following subclauses describe the semantics of the core sections and provide some examples. The
829 sections are used in several places of an OVF envelope; the description of each section defines where it
830 may be used. See the OVF schema for a detailed specification of all attributes and elements.
831 In the OVF schema, all sections are part of a substitution group with the Section element as head of the
832 substitution group. The Section element is abstract and cannot be used directly.

833 9.1 DiskSection

834 A DiskSection describes meta-information about virtual disks in the OVF package. Virtual disks and
835 their metadata are described outside the virtual hardware to facilitate sharing between virtual machines
836 within an OVF package.
837 EXAMPLE: The following example shows a description of virtual disks:
838 <DiskSection>
839 <Info>Describes the set of virtual disks</Info>
840 <Disk ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:capacity="8589934592"
841 ovf:populatedSize="3549324972"
842 ovf:format=
843 "http://www.vmware.com/interfaces/specifications/vmdk.html#sparse">
844 </Disk>
845 <Disk ovf:diskId="vmdisk2" ovf:capacity="536870912"
846 </Disk>
847 <Disk ovf:diskId="vmdisk3" ovf:capacity="${disk.size}"
848 ovf:capacityAllocationUnits="byte * 2^30"
849 </Disk>
850 </DiskSection>
851 DiskSection is a valid section at the outermost envelope level only.
852 Each virtual disk is represented by a Disk element that shall be given an identifier using the
853 ovf:diskId attribute; the identifier shall be unique within the DiskSection.
854 The capacity of a virtual disk shall be specified by the ovf:capacity attribute with an xs:long integer
855 value. The default unit of allocation shall be bytes. The optional string attribute
856 ovf:capacityAllocationUnits may be used to specify a particular unit of allocation. Values for
857 ovf:capacityAllocationUnits shall match the format for programmatic units defined in DSP0004
858 with the restriction that the base unit shall be "byte".
859 The ovf:fileRef attribute denotes the virtual disk content by identifying an existing File element in
860 the References element, the File element is identified by matching its ovf:id attribute value with the
861 ovf:fileRef attribute value. Omitting the ovf:fileRef attribute shall indicate an empty disk. In this
862 case, the disk shall be created and the entire disk content zeroed at installation time. The guest software
863 will typically format empty disks in some file system format.
864 The format URI (see 5.2) of a non-empty virtual disk shall be specified by the ovf:format attribute.
865 Different Disk elements shall not contain ovf:fileRef attributes with identical values. Disk elements
866 shall be ordered such that they identify any File elements in the same order as these are defined in the
867 References element.
868 For empty disks, rather than specifying a fixed virtual disk capacity, the capacity for an empty disk may be
869 given using an OVF property, for example ovf:capacity="${disk.size}". The OVF property shall
870 resolve to an xs:long integer value. See 9.5 for a description of OVF properties. The
871 ovf:capacityAllocationUnits attribute is useful when using OVF properties because a user may
872 be prompted and can then enter disk sizing information in ,for example, gigabytes.
873 For non-empty disks, the actual used size of the disk may optionally be specified using the
874 ovf:populatedSize attribute. The unit of this attribute is always bytes. ovf:populatedSize is
875 allowed to be an estimate of used disk size but shall not be larger than ovf:capacity.

876 In VirtualHardwareSection, virtual disk devices may have a rasd:HostResource element

877 referring to a Disk element in DiskSection; see 8.3. The virtual disk capacity shall be defined by the
878 ovf:capacity attribute on the Disk element. If a rasd:VirtualQuantity element is specified along
879 with the rasd:HostResource element, the virtual quantity value shall not be considered and may have
880 any value.
881 OVF allows a disk image to be represented as a set of modified blocks in comparison to a parent image.
882 The use of parent disks can often significantly reduce the size of an OVF package, if it contains multiple
883 disks with similar content. For a Disk element, a parent disk may optionally be specified using the
884 ovf:parentRef attribute, which shall contain a valid ovf:diskId reference to a different Disk
885 element. If a disk block does not exist locally, lookup for that disk block then occurs in the parent disk. In
886 DiskSection, parent Disk elements shall occur before child Disk elements that refer to them.
887 9.2 NetworkSection

888 The NetworkSection element shall list all logical networks used in the OVF package.
889 <NetworkSection>
890 <Info>List of logical networks used in the package</Info>
891 <Network ovf:name="red">
892 <Description>The network the Red service is available on</Description>
893 </Network>
894 <Network ovf:name="blue">
895 <Description>The network the Blue service is available on</Description>
896 </Network>
897 </NetworkSection>
898 NetworkSection is a valid element at the outermost envelope level.
899 All networks referred to from Connection elements in all VirtualHardwareSection elements shall
900 be defined in the NetworkSection.
901 9.3 ResourceAllocationSection

902 The ResourceAllocationSection element describes all resource allocation requirements of a
903 VirtualSystemCollection entity. These resource allocations shall be performed when deploying the
904 OVF package.
905 <ResourceAllocationSection>
906 <Info>Defines reservations for CPU and memory for the collection of VMs</Info>
907 <Item>
909 <rasd:ElementName>300 MB reservation</rasd:ElementName>
913 </Item>
914 <Item ovf:configuration="..." ovf:bound="...">
915 <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
916 <rasd:ElementName>500 MHz reservation</rasd:ElementName>

920 </Item>
921 </ResourceAllocationSection>
922 ResourceAllocationSection is a valid element for a VirtualSystemCollection entity.
923 The optional ovf:configuration attribute contains a list of configuration names. See 9.8 on
924 deployment options for semantics of this attribute.
925 The optional ovf:bound attribute contains a value of min, max, or normal. See 8.4 for semantics of this
926 attribute.
927 9.4 AnnotationSection

928 The AnnotationSection element is a user-defined annotation on an entity. Such annotations may be
929 displayed when deploying the OVF package.
930 <AnnotationSection>
931 <Info>An annotation on this service. It can be ignored</Info>
932 <Annotation>Contact customer support if you have any problems</Annotation>
933 </AnnotationSection >
934 AnnotationSection is a valid element for a VirtualSystem and a VirtualSystemCollection

935 entity.
936 See clause 10 for details on how to localize the Annotation element.
937 9.5 ProductSection

938 The ProductSection element specifies product-information for an appliance, such as product name,
939 version, and vendor.
940 <ProductSection ovf:class="com.mycrm.myservice" ovf:instance="1">
941 <Info>Describes product information for the service</Info>
942 <Product>MyCRM Enterprise</Product>
943 <Vendor>MyCRM Corporation</Vendor>
944 <Version>4.5</Version>
945 <FullVersion>4.5-b4523</FullVersion>
946 <ProductUrl>http://www.mycrm.com/enterprise</ProductUrl>
947 <VendorUrl>http://www.mycrm.com</VendorUrl>
948 <Icon ovf:height="32" ovf:width="32" ovf:mimeType="image/png" ovf:fileRef="icon">
949 <Category>Email properties</Category>
950 <Property ovf:key="admin.email" ovf:type="string" ovf:userConfigurable="true">
951 <Label>Admin email</Label>
952 <Description>Email address of administrator</Description>
953 </Property>
954 <Category>Admin properties</Category>
955 <Property ovf:key="app.log" ovf:type="string" ovf:value="low"
956 ovf:userConfigurable="true">
957 <Description>Loglevel for the service</Description>
958 </Property>
959 <Property ovf:key="app.isSecondary" ovf:value="false" ovf:type="boolean">
960 <Description>Cluster setup for application server</Description>
961 </Property>
962 <Property ovf:key="app.ip" ovf:type="string" ovf:value="${appserver-vm}">

963 <Description>IP address of the application server VM</Description>

964 </Property>
965 </ProductSection>
966 The optional Product element specifies the name of the product, while the optional Vendor element
967 specifies the name of the product vendor. The optional Version element specifies the product version in
968 short form, while the optional FullVersion element describes the product version in long form. The
969 optional ProductUrl element specifies a URL which shall resolve to a human readable description of
970 the product, while the optional VendorUrl specifies a URL which shall resolve to a human readable
971 description of the vendor.
972 The optional AppUrl element specifies a URL resolving to the deployed product instance; this element is
973 experimental. The optional Icon element specifies display icons for the product; this element is
974 experimental.
975 Property elements specify application-level customization parameters and are particularly relevant to
976 appliances that need to be customized during deployment with specific settings such as network identity,
977 the IP addresses of DNS servers, gateways, and others.
978 ProductSection is a valid section for a VirtualSystem and a VirtualSystemCollection entity.
979 Property elements may be grouped by using Category elements. The set of Property elements
980 grouped by a Category element is the sequence of Property elements following the Category
981 element, until but not including an element that is not a Property element. For OVF packages
982 containing a large number of Property elements, this may provide a simpler installation experience.
983 Similarly, each Property element may have a short label defined by its Label child element in addition
984 to a description defined by its Description child element. See clause 10 for details on how to localize
985 the Category element and the Description and Label child elements of the Property element.
986 Each Property element in a ProductSection shall be given an identifier that is unique within the
987 ProductSection using the ovf:key attribute.
988 Each Property element in a ProductSection shall be given a type using the ovf:type attribute and
989 optionally type qualifiers using the ovf:qualifiers attribute. Valid types are listed in Table 6, and valid
990 qualifiers are listed in Table 7.
991 The optional attribute ovf:value is used to provide a default value for a property. One or more optional
992 Value elements may be used to define alternative default values for specific configurations, as defined in
993 9.8.
994 The optional attribute ovf:userConfigurable determines whether the property value is configurable
995 during the installation phase. If ovf:userConfigurable is FALSE or omitted, the ovf:value attribute
996 specifies the value to be used for that customization parameter during installation. If
997 ovf:userConfigurable is TRUE, the ovf:value attribute specifies a default value for that
998 customization parameter, which may be changed during installation.
999 A simple OVF implementation such as a command-line installer typically uses default values for
1000 properties and does not prompt even though ovf:userConfigurable is set to TRUE. To force
1001 prompting at startup time, omitting the ovf:value attribute is sufficient for integer types, because the
1002 empty string is not a valid integer value. For string types, prompting may be forced by adding a qualifier
1003 requiring a non-empty string, see Table 7.
1004 The optional Boolean attribute ovf:password indicates that the property value may contain sensitive
1005 information. The default value is FALSE. OVF implementations prompting for property values are advised
1006 to obscure these values when ovf:password is set to TRUE. This is similar to HTML text input of type
1007 password. Note that this mechanism affords limited security protection only. Although sensitive values

1008 are masked from casual observers, default values in the OVF descriptor and assigned values in the OVF
1009 environment are still passed in clear text.
1010 Zero or more ProductSections may be specified within a VirtualSystem or

1011 VirtualSystemCollection. Typically, a ProductSection corresponds to a particular software
1012 product that is installed. Each product section at the same entity level shall have a unique ovf:class
1013 and ovf:instance attribute pair. For the common case where only a single ProductSection is used,
1014 the ovf:class and ovf:instance attributes are optional and default to the empty string. It is
1015 recommended that the ovf:class property be used to uniquely identify the software product using the
1016 reverse domain name convention. Examples of values are com.vmware.tools and
1017 org.apache.tomcat. If multiple instances of the same product are installed, the ovf:instance
1018 attribute is used to identify the different instances.
1019 Property elements are exposed to the guest software through the OVF environment, as described in
1020 clause 11. The value of the ovfenv:key attribute of a Property element exposed in the OVF
1021 environment shall be constructed from the value of the ovf:key attribute of the corresponding
1022 Property element defined in a ProductSection entity of an OVF descriptor as follows:
1023 key-value-env = [class-value "."] key-value-prod ["." instance-value]
1024 where:
1025 • class-value is the value of the ovf:class attribute of the Property element defined in the
1026 ProductSection entity. The production [class-value "."] shall be present if and only if
1027 class-value is not the empty string.
1028 • key-value-prod is the value of the ovf:key attribute of the Property element defined in the
1029 ProductSection entity.
1030 • instance-value is the value of the ovf:instance attribute of the Property element defined in
1031 the ProductSection entity. The production ["." instance-value] shall be present if and only
1032 if instance-value is not the empty string.
1033 EXAMPLE: The following OVF environment example shows how properties can be propagated to the guest
1034 software:
1035 <Property ovf:key="com.vmware.tools.logLevel" ovf:value="none"/>
1036 <Property ovf:key="org.apache.tomcat.logLevel.1" ovf:value="debug"/>
1037 <Property ovf:key="org.apache.tomcat.logLevel.2" ovf:value="normal"/>
1038
1039 The consumer of an OVF package should prompt for properties where ovf:userConfigurable is
1040 TRUE. These properties may be defined in multiple ProductSections as well as in sub-entities in the
1041 OVF package.
1042 If a ProductSection exists, then the first ProductSection entity defined in the top-level Content
1043 element of a package shall define summary information that describes the entire package. After
1044 installation, a consumer of the OVF package could choose to make this information available as an
1045 instance of the CIM_Product class.
1046 Property elements specified on a VirtualSystemCollection are also seen by its immediate
1047 children (see clause 11). Children may refer to the properties of a parent VirtualSystemCollection
1048 using macros on the form ${name} as value for ovf:value attributes.
1049 Table 6 lists the valid types for properties. These are a subset of CIM intrinsic types defined in DSP0004,
1050 which also define the value space and format for each intrinsic type. Each Property element shall
1051 specify a type using the ovf:type attribute.

1052 Table 6 – Property Types

Type Description
uint8 Unsigned 8-bit integer
sint8 Signed 8-bit integer
string String
boolean Boolean
real32 IEEE 4-byte floating point
real64 IEEE 8-byte floating point
1053 Table 7 lists the supported CIM type qualifiers as defined in DSP0004. Each Property element may
1054 optionally specify type qualifiers using the ovf:qualifiers attribute with multiple qualifiers separated
1055 by commas; see production qualifierList in ANNEX A “MOF Syntax Grammar Description” in
1056 DSP0004.
1057 Table 7 – Property Qualifiers

Type Description
string MinLen(min)
MaxLen(max)
ValueMap{...}
uint8 ValueMap{...}
sint8
uint16
sint16
uint32
sint32
uint64
sint64
1058 9.6 EulaSection

1059 A EulaSection contains the legal terms for using its parent Content element. This license shall be
1060 shown and accepted during deployment of an OVF package. Multiple EulaSections may be present in
1061 an OVF. If unattended installations are allowed, all embedded license sections are implicitly accepted.
1062 <EulaSection>
1063 <Info>Licensing agreement</Info>
1064 <License>
1065 Lorem ipsum dolor sit amet, ligula suspendisse nulla pretium, rhoncus tempor placerat
1066 fermentum, enim integer ad vestibulum volutpat. Nisl rhoncus turpis est, vel elit,
1067 congue wisi enim nunc ultricies sit, magna tincidunt. Maecenas aliquam maecenas ligula

1068 nostra, accumsan taciti. Sociis mauris in integer, a dolor netus non dui aliquet,
1069 sagittis felis sodales, dolor sociis mauris, vel eu libero cras. Interdum at. Eget
1070 habitasse elementum est, ipsum purus pede porttitor class, ut adipiscing, aliquet sed
1071 auctor, imperdiet arcu per diam dapibus libero duis. Enim eros in vel, volutpat nec
1072 pellentesque leo, scelerisque.
1073 </License>
1074 </EulaSection>
1075 EulaSection is a valid section for a VirtualSystem and a VirtualSystemCollection entity.
1076 See clause 10 for details on how to localize the License element.
1077 9.7 StartupSection

1078 The StartupSection specifies how a virtual machine collection is powered on and off.
1079 <StartupSection>
1080 <Item ovf:id="vm1" ovf:order="0" ovf:startDelay="30" ovf:stopDelay="0"
1081 ovf:startAction="powerOn" ovf:waitingForGuest="true"
1082 ovf:stopAction="powerOff"/>
1083 <Item ovf:id="teamA" ovf:order="0"/>
1084 <Item ovf:id="vm2" ovf:order="1" ovf:startDelay="0" ovf:stopDelay="20"
1085 ovf:startAction="powerOn" ovf:stopAction="guestShutdown"/>
1086 </StartupSection>
1087 Each Content element that is a direct child of a VirtualSystemCollection may have a
1088 corresponding Item element in the StartupSection entity of the VirtualSystemCollection entity.
1089 Note that Item elements may correspond to both VirtualSystem and VirtualSystemCollection
1090 entities. When a start or stop action is performed on a VirtualSystemCollection entity, the
1091 respective actions on the Item elements of its StartupSection entity are invoked in the specified
1092 order. Whenever an Item element corresponds to a (nested) VirtualSystemCollection entity, the
1093 actions on the Item elements of its StartupSection entity shall be invoked before the action on the
1094 Item element corresponding to that VirtualSystemCollection entity is invoked (i.e., depth-first
1095 traversal).
1096 The following required attributes on Item are supported for a VirtualSystem and
1097 VirtualSystemCollection:
1098 • ovf:id shall match the value of the ovf:id attribute of a Content element which is a direct
1099 child of this VirtualSystemCollection. That Content element describes the virtual
1100 machine or virtual machine collection to which the actions defined in the Item element apply.
1101 • ovf:order specifies the startup order using non-negative integer values. The order of
1102 execution of the start action is the numerical ascending order of the values. Items with same
1103 order identifier may be started up concurrently. The order of execution of the stop action is the
1104 numerical descending order of the values.
1105 The following optional attributes on Item are supported for a VirtualSystem.
1106 • ovf:startDelay specifies a delay in seconds to wait until proceeding to the next order in the
1107 start sequence. The default value is 0.
1108 • ovf:waitingForGuest enables the platform to resume the startup sequence after the guest
1109 software has reported it is ready. The interpretation of this is deployment platform specific. The
1110 default value is FALSE.
1111 • ovf:startAction specifies the start action to use. Valid values are powerOn and none. The
1112 default value is powerOn.

1113 • ovf:stopDelay specifies a delay in seconds to wait until proceeding to the previous order in
1114 the stop sequence. The default value is 0.
1115 • ovf:stopAction specifies the stop action to use. Valid values are powerOff,
1116 guestShutdown, and none. The interpretation of guestShutdown is deployment platform
1117 specific. The default value is powerOff.
1118 If not specified, an implicit default Item is created for each entity in the collection with ovf:order="0".
1119 Thus, for a trivial startup sequence no StartupSection needs to be specified.
1120 9.8 DeploymentOptionSection

1121 The DeploymentOptionSection specifies a discrete set of intended resource configurations. The
1122 author of an OVF package can include sizing metadata for different configurations. A consumer of the
1123 OVF shall select a configuration, for example, by prompting the user. The selected configuration is visible
1124 in the OVF environment, enabling guest software to adapt to the selected configuration. See clause 11.
1125 The DeploymentOptionSection specifies an ID, label, and description for each configuration.
1126 <DeploymentOptionSection>
1127 <Configuration ovf:id="Minimal">
1128 <Label>Minimal</Label>
1129 <Description>Some description</Description>
1130 </Configuration>
1131 <Configuration ovf:id="Typical" ovf:default="true">
1132 <Label>Typical</Label>
1133 <Description>Some description</Description>
1134 </Configuration>
1135 
1136 </DeploymentOptionSection>
1137 The DeploymentOptionSection has the following semantics:

1138 • If present, the DeploymentOptionSection is valid only at the envelope level, and only one
1139 section shall be specified in an OVF descriptor.
1140 • The discrete set of configurations is described with Configuration elements, which shall
1141 have identifiers specified by the ovf:id attribute that are unique in the package.
1142 • A default Configuration element may be specified with the optional ovf:default attribute.
1143 If no default is specified, the first element in the list is the default. Specifying more than one
1144 element as the default is invalid.
1145 • The Label and Description elements are localizable using the ovf:msgid attribute. See
1146 clause 10 for more details on internationalization support.
1147 Configurations may be used to control resources for virtual hardware and for virtual machine collections.
1148 Item elements in VirtualHardwareSection elements describe resources for VirtualSystem entities,
1149 while Item elements in ResourceAllocationSection elements describe resources for virtual
1150 machine collections. For these two Item types, the following additional semantics are defined:
1151 • Each Item has an optional ovf:configuration attribute, containing a list of configurations
1152 separated by a single space character. If not specified, the item shall be selected for any
1153 configuration. If specified, the item shall be selected only if the chosen configuration ID is in the
1154 list. A configuration attribute shall not contain an ID that is not specified in the
1155 DeploymentOptionSection.

1156 • Within a single VirtualHardwareSection or ResourceAllocationSection, multiple

1157 Item elements are allowed to refer to the same InstanceID. A single combined Item for the
1158 given InstanceID shall be constructed by picking up the child elements of each Item element,
1159 with child elements of a former Item element in the OVF descriptor not being picked up if there
1160 is a like-named child element in a latter Item element. Any attributes specified on child
1161 elements of Item elements that are not picked up that way, are not part of the combined Item
1162 element.
1163 • All Item elements shall specify ResourceType, and Item elements with the same InstanceID
1164 shall agree on ResourceType.
1165 EXAMPLE 1: The following example shows a VirtualHardwareSection:
1166 <VirtualHardwareSection>
1167 <Info>...</Info>
1168 <Item>
1170 <rasd:ElementName>512 MB memory size and 256 MB
1171 reservation</rasd:ElementName>
1176 </Item>
1177 ...
1178 <Item ovf:configuration="big">
1180 <rasd:ElementName>1024 MB memory size and 512 MB
1181 reservation</rasd:ElementName>
1186 </Item>
1188 Note that the attributes ovf:configuration and ovf:bound on Item may be used in combination to
1189 provide very flexible configuration options.
1190 Configurations can further be used to control default values for properties. For Property elements inside
1191 a ProductSection, the following additional semantic is defined:
1192 • It is possible to use alternative default property values for different configurations in a
1193 DeploymentOptionSection. In addition to a Label and Description element, each
1194 Property element may optionally contain Value elements. The Value element shall have
1195 an ovf:value attribute specifying the alternative default and an ovf:configuration
1196 attribute specifying the configuration in which this new default value should be used. Multiple
1197 Value elements shall not refer to the same configuration.
1198 EXAMPLE 2: The following shows an example ProductSection:
1199 <ProductSection>
1200 <Property ovf:key="app.log" ovf:type="string" ovf:value="low"
1201 ovf:userConfigurable="true">
1202 <Label>Loglevel</Label>

1203 <Description>Loglevel for the service</Description>

1204 <Value ovf:value="none" ovf:configuration="minimal">
1205 </Property>
1206 </ProductSection>
1207 9.9 OperatingSystemSection

1208 An OperatingSystemSection specifies the operating system installed on a virtual machine.
1209 <OperatingSystemSection ovf:id="76">
1210 <Info>Specifies the operating system installed</Info>
1211 <Description>Microsoft Windows Server 2008</Description>
1212 </OperatingSystemSection>
1213 The valid values for ovf:id are defined by the ValueMap qualifier in the
1214 CIM_OperatingSystem.OsType property.
1215 OperatingSystemSection is a valid section for a VirtualSystem entity only.
1216 9.10 InstallSection

1217 The InstallSection, if specified, indicates that the virtual machine needs to be booted once in order
1218 to install and/or configure the guest software. The guest software is expected to access the OVF
1219 environment during that boot, and to shut down after having completed the installation and/or
1220 configuration of the software, powering off the guest.
1221 If the InstallSection is not specified, this indicates that the virtual machine does not need to be
1222 powered on to complete installation of guest software.
1223 <InstallSection ovf:initialBootStopDelay="300">
1224 <Info>Specifies that the virtual machine needs to be booted once after having
1225 created the guest software in order to install and/or configure the software
1226 </Info>
1227 </InstallSection>
1228 InstallSection is a valid section for a VirtualSystem entity only.
1229 The optional ovf:initialBootStopDelay attribute specifies a delay in seconds to wait for the virtual
1230 machine to power off. If not set, the implementation shall wait for the virtual machine to power off by itself.
1231 If the delay expires and the virtual machine has not powered off, the consumer of the OVF package shall
1232 indicate a failure.
1233 Note that the guest software in the virtual machine can do multiple reboots before powering off.
1234 Several VMs in a virtual machine collection may have an InstallSection defined, in which case the
1235 above step is done for each VM, potentially concurrently.
1236 10 Internationalization
1237 The following elements support localizable messages using the optional ovf:msgid attribute:
1238 • Info element on Content
1239 • Name element on Content
1240 • Info element on Section

1241 • Annotation element on AnnotationSection

1242 • License element on EulaSection
1243 • Description element on NetworkSection
1244 • Description element on OperatingSystemSection
1245 • Description, Product, Vendor, Label, and Category elements on ProductSection
1246 • Description and Label elements on Property
1247 • Description and Label elements on DeploymentOptionSection
1248 • ElementName, Caption and Description subelements on the System element in
1249 VirtualHardwareSection
1250 • ElementName, Caption and Description subelements on Item elements in
1251 VirtualHardwareSection
1252 • ElementName, Caption and Description subelements on Item elements in
1253 ResourceAllocationSection
1254 The ovf:msgid attribute contains an identifier that refers to a message that may have different values in
1255 different locales.
1256 EXAMPLE 1:
1257 <Info ovf:msgid="info.text">Default info.text value if no locale is set or no locale
1258 match</Info>
1259 <License ovf:msgid="license.tomcat-6_0"/> 
1260 The xml:lang attribute on the Envelope element shall specify the default locale for messages in the
1261 descriptor. The attribute is optional with a default value of "en-US".
1262 Message resource bundles can be internal or external to the OVF descriptor. Internal resource bundles
1263 are represented as Strings elements at the end of the Envelope element.
1264 EXAMPLE 2:
1265 <ovf:Envelope xml:lang="en-US">
1266 ...
1267 ... sections and content here ...
1268 ...
1269 <Info msgid="info.os">Operating System</Info>
1270 ...
1271 <Strings xml:lang="da-DA">
1272 <Msg ovf:msgid="info.os">Operativsystem</Msg>
1273 ...
1274 </Strings>
1275 <Strings xml:lang="de-DE">
1276 <Msg ovf:msgid="info.os">Betriebssystem</Msg>
1277 ...
1278 </Strings>
1279 </ovf:Envelope>
1280 External resource bundles shall be listed first in the References section and referred to from Strings
1281 elements. An external message bundle follows the same schema as the embedded one. Exactly one
1282 Strings element shall be present in an external message bundle, and that Strings element may not
1283 have an ovf:fileRef attribute specified.

1284 EXAMPLE 3:
1285 <ovf:Envelope xml:lang="en-US">
1286 <References>
1287 ...
1288 <File ovf:id="it-it-resources" ovf:href="resources/it-it-bundle.msg"/>
1289 </References>
1290 ... sections and content here ...
1291 ...
1292 <Strings xml:lang="it-IT" ovf:fileRef="it-it-resources"/>
1293 ...
1294 </ovf:Envelope>
1295 EXAMPLE 4: Example content of external resources/it-it-bundle.msg file, which is referenced in previous example:
1296 <Strings
1297 xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
1298 xmlns="http://schemas.dmtf.org/ovf/envelope/1"
1299 xml:lang="it-IT">
1300 <Msg ovf:msgid="info.os">Sistema operativo</Msg>
1301 ...
1302 </Strings>
1303 The embedded and external Strings elements may be interleaved, but they shall be placed at the end
1304 of the Envelope element. If multiple occurrences of a msg:id attribute with a given locale occur, a latter
1305 value overwrites a former.
1306 11 OVF Environment

1307 The OVF environment defines how the guest software and the deployment platform interact. This
1308 environment allows the guest software to access information about the deployment platform, such as the
1309 user-specified values for the properties defined in the OVF descriptor.
1310 The environment specification is split into a protocol part and a transport part. The protocol part defines
1311 the format and semantics of an XML document that can be made accessible to the guest software. The
1312 transport part defines how the information is communicated between the deployment platform and the
1313 guest software.
1314 The dsp8027_1.1.0.xsd XML schema definition file for the OVF environment contains the elements
1315 and attributes.
1316 11.1 Environment Document

1317 The environment document is an extensible XML document that is provided to the guest software about
1318 the environment in which it is being executed. The way that the document is obtained depends on the
1319 transport type.
1320 EXAMPLE: An example of the structure of the OVF environment document follows:
1321 <?xml version="1.0" encoding="UTF-8"?>
1322 <Environment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1323 xmlns:ovfenv="http://schemas.dmtf.org/ovf/environment/1"
1324 xmlns="http://schemas.dmtf.org/ovf/environment/1"
1325 ovfenv:id="identification of VM from OVF descriptor">
1326 
1327 <PlatformSection>
1328 <Kind>Type of virtualization platform</Kind>

1329 <Version>Version of virtualization platform</Version>

1330 <Vendor>Vendor of virtualization platform</Vendor>
1331 <Locale>Language and country code</Locale>
1332 <TimeZone>Current timezone offset in minutes from UTC</TimeZone>
1333 </PlatformSection>
1334 
1335 <PropertySection>
1336 <Property ovfenv:key="key" ovfenv:value="value">
1337 
1338 </PropertySection>
1339 <Entity ovfenv:id="id of sibling virtual system or virtual system collection">
1340 <PropertySection>
1341 
1342 </PropertySection>
1343 </Entity>
1344 </Environment>
1345 The value of the ovfenv:id attribute of the Environment element shall match the value of the ovf:id
1346 attribute of the VirtualSystem entity describing this virtual machine.
1347 The PlatformSection element contains optional information provided by the deployment platform.
1348 Elements Kind, Version, and Vendor describe deployment platform vendor details; these elements are
1349 experimental. Elements Locale and TimeZone describe the current locale and time zone; these
1350 elements are experimental.
1351 The PropertySection element contains Property elements with key/value pairs corresponding to all
1352 properties specified in the OVF descriptor for the current virtual machine, as well as properties specified
1353 for the immediate parent VirtualSystemCollection, if one exists. The environment presents
1354 properties as a simple list to make it easy for applications to parse. Furthermore, the single list format
1355 supports the override semantics where a property on a VirtualSystem may override one defined on a
1356 parent VirtualSystemCollection. The overridden property shall not be in the list. Overriding may
1357 occur if a property in the current virtual machine and a property in the parent
1358 VirtualSystemCollection has identical ovf:key, ovf:class, and ovf:instance attribute
1359 values; see 9.5. In this case, the value of an overridden parent property may be obtained by adding a
1360 differently named child property referencing the parent property with a macro; see 9.5.
1361 An Entity element shall exist for each sibling VirtualSystem and VirtualSystemCollection, if
1362 any are present. The value of the ovfenv:id attribute of the Entity element shall match the value of
1363 the ovf:id attribute of the sibling entity. The Entity elements contain the property key/value pairs in
1364 the sibling’s OVF environment documents, so the content of an Entity element for a particular sibling
1365 shall contain the exact PropertySection seen by that sibling. This information can be used, for
1366 example, to make configuration information such as IP addresses available to VirtualSystems being
1367 part of a multi-tiered application.
1368 Table 8 shows the core sections that are defined.

1369 Table 8 – Core Sections

Section Location Multiplicity
PlatformSection Environment Zero or one
Provides information from the deployment platform
PropertySection Environment Zero or one
Contains key/value pairs corresponding to properties Entity
defined in the OVF descriptor
1370 The environment document is extensible by providing new section types. A consumer of the document
1371 should ignore unknown section types and elements.
1372 11.2 Transport

1373 The environment document information can be communicated in a number of ways to the guest software.
1374 These ways are called transport types. The transport types are specified in the OVF descriptor by the
1375 ovf:transport attribute of VirtualHardwareSection. Several transport types may be specified,
1376 separated by a single space character, in which case an implementation is free to use any of them. The
1377 transport types define methods by which the environment document is communicated from the
1378 deployment platform to the guest software.
1379 To enable interoperability, this specification defines an "iso" transport type which all implementations
1380 that support CD-ROM devices are required to support. The iso transport communicates the environment
1381 document by making a dynamically generated ISO image available to the guest software. To support the
1382 iso transport type, prior to booting a virtual machine, an implementation shall make an ISO read-only
1383 disk image available as backing for a disconnected CD-ROM. If the iso transport is selected for a
1384 VirtualHardwareSection, at least one disconnected CD-ROM device shall be present in this section.
1385 The generated ISO image shall comply with the ISO 9660 specification with support for Joliet extensions.
1386 The ISO image shall contain the OVF environment for this particular virtual machine, and the environment
1387 shall be present in an XML file named ovf-env.xml that is contained in the root directory of the ISO
1388 image. The guest software can now access the information using standard guest operating system tools.
1389 If the virtual machine prior to booting had more than one disconnected CD-ROM, the guest software may
1390 have to scan connected CD-ROM devices in order to locate the ISO image containing the ovf-env.xml
1391 file.
1392 The ISO image containing the OVF environment shall be made available to the guest software on every
1393 boot of the virtual machine.
1394 Support for the "iso" transport type is not a requirement for virtual hardware architectures or guest
1395 operating systems which do not have CD-ROM device support.
1396 To be compliant with this specification, any transport format other than iso shall be given by a URI which
1397 identifies an unencumbered specification on how to use the transport. The specification need not be
1398 machine readable, but it shall be static and unique so that it may be used as a key by software reading an
1399 OVF descriptor to uniquely determine the format. The specification shall be sufficient for a skilled person
1400 to properly interpret the transport mechanism for implementing the protocols. It is recommended that
1401 these URIs are resolvable.

1402 ANNEX A
1403 (informative)
1404
1405 Symbols and Conventions
1406 XML examples use the XML namespace prefixes defined in Table 1. The XML examples use a style to
1407 not specify namespace prefixes on child elements. Note that XML rules define that child elements
1408 specified without namespace prefix are from the namespace of the parent element, and not from the
1409 default namespace of the XML document. Throughout the document, whitespace within XML element
1410 values is used for readability. In practice, a service can accept and strip leading and trailing whitespace
1411 within element values as if whitespace had not been used.
1412 Syntax definitions in Augmented BNF (ABNF) use ABNF as defined in IETF RFC5234 with the following
1413 exceptions:
1414 • Rules separated by a bar (|) represent choices, instead of using a forward slash (/) as defined in
1415 ABNF.
1416 • Any characters must be processed case sensitively, instead of case-insensitively as defined in
1417 ABNF.
1418 • Whitespace (i.e., the space character U+0020 and the tab character U+0009) is allowed between
1419 syntactical elements, instead of assembling elements without whitespace as defined in ABNF.
1420

1421 ANNEX B
1422 (informative)
1423
1424 Change Log
Version Date Description
1.0.0 2009-02-22 DMTF Standard
1.1.0 2010-01-12 DMTF Standard
1425

1426 ANNEX C
1427 (normative)
1428
1429 OVF XSD
1430 Normative copies of the XML schemas for this specification may be retrieved by resolving the following
1431 URLs:
1432
1433 http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd
1434 http://schemas.dmtf.org/ovf/environment/1/dsp8027_1.1.0.xsd
1435 Any xs:documentation content in XML schemas for this specification is informative and provided only
1436 for convenience.
1437 Normative copies of the XML schemas for the WS-CIM mapping (DSP0230) of
1438 CIM_ResourceAllocationSystemSettingsData and CIM_VirtualSystemSettingData may be
1439 retrieved by resolving the following URLs:
1440
1441 http://schemas.dmtf.org/wbem/wscim/1/cim-
1442 schema/2.22.0/CIM_VirtualSystemSettingData.xsd
1443 http://schemas.dmtf.org/wbem/wscim/1/cim-
1444 schema/2.22.0/CIM_ResourceAllocationSettingData.xsd
1445 This specification is based on the following CIM MOFs:

1446 CIM_VirtualSystemSettingData.mof
1447 CIM_ResourceAllocationSettingData.mof
1448 CIM_OperatingSystem.mof
1449

1450 Bibliography
1451 ISO 9660, Joliet Extensions Specification, May 1995,

1452 http://bmrc.berkeley.edu/people/chaffee/jolspec.html
1453 W3C, Y. Savourel et al, Best Practices for XML Internationalization, Working Draft, October 2007,
1454 http://www.w3.org/TR/2007/WD-xml-i18n-bp-20071031
1455 DMTF DSP1044, Processor Device Resource Virtualization Profile 1.0

1457 DMTF DSP1045, Memory Resource Virtualization Profile 1.0

1459 DMTF DSP1047, Storage Resource Virtualization Profile 1.0

1461 DMTF DSP1022, CPU Profile 1.0,

1463 DMTF DSP1026, System Memory Profile 1.0,

1465 DMTF DSP1014, Ethernet Port Profile 1.0,

1467 DSP1050, Ethernet Port Resource Virtualization Profile 1.0

1469

Open Virtualization Format Specification: Document Number: DSP0243 Date: 2010-01-12

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Open Virtualization Format Specification: Document Number: DSP0243 Date: 2010-01-12

Загружено:

Авторское право:

Доступные форматы

1

2 Document Number: DSP0243

5 Open Virtualization Format Specification

6 Document Type: Specification

7 Document Status: DMTF Standard

2 DMTF Standard Version 1.1.0

Version 1.1.0 DMTF Standard 3

4 DMTF Standard Version 1.1.0

Version 1.1.0 DMTF Standard 5

6 DMTF Standard Version 1.1.0

147 Open Virtualization Format Specification

151 2 Normative References

158 DMTF CIM Schema 2.22,

162 DMTF DSP0230, WS-CIM Mapping Specification 1.0,

164 DMTF DSP1041, Resource Allocation Profile (RAP) 1.1,

166 DMTF DSP1043, Allocation Capabilities Profile (ACP) 1.0,

Version 1.1.0 DMTF Standard 7

182 3 Terms and Definitions

8 DMTF Standard Version 1.1.0

Version 1.1.0 DMTF Standard 9

261 4 Symbols and Abbreviated Terms

275 5 OVF Packages

278 • one OVF descriptor with extension .ovf

279 • zero or one OVF manifest with extension .mf

280 • zero or one OVF certificate with extension .cert

281 • zero or more disk image files

282 • zero or more additional resource files, such as ISO images

10 DMTF Standard Version 1.1.0

300 The format of the manifest file is as follows:

Version 1.1.0 DMTF Standard 11

343 -----BEGIN CERTIFICATE-----

361 5.2 Virtual Disk Formats

369 5.3 Distribution as a Single File

12 DMTF Standard Version 1.1.0

387 5) OVF manifest (optional)

398 5.4 Distribution as a Set of Files

406 6 OVF Descriptor

419 Table 1 – XML Namespace Prefixes

Version 1.1.0 DMTF Standard 13

420 7 Envelope Element

14 DMTF Standard Version 1.1.0

478 7.1 File References

Version 1.1.0 DMTF Standard 15

537 7.2 Content Element

547 The structure of a VirtualSystem element is as follows:

556 The VirtualSystemCollection element is a container of multiple VirtualSystem or

16 DMTF Standard Version 1.1.0

560 The structure of a VirtualSystemCollection element is as follows:

577 7.3 Extensibility

588 • The OVF schemas allow additional attributes on existing types.

Version 1.1.0 DMTF Standard 17

624 7.4 Conformance

18 DMTF Standard Version 1.1.0

641 8 Virtual Hardware Description

670 A VirtualSystem element shall have a VirtualHardwareSection direct child element.

Version 1.1.0 DMTF Standard 19

698 8.2 Extensibility

705 Table 2 – Actions for Child Elements with ovf:required Attribute

Child Element ovf:required Attribute Value Action

706 8.3 Virtual Hardware Elements

20 DMTF Standard Version 1.1.0

722 <rasd:Limit> ... </rasd:Limit>