• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
423
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1 2 3 Document Number: DSP0243 4 Date: 2009-02-22 5 Version: 1.0.0 6 Open Virtualization Format Specification 7 Document Type: Specification 8 Document Status: DMTF Standard 9 Document Language: E
  • 2. Open Virtualization Format Specification DSP0243 10 Copyright notice 11 Copyright © 2009 Distributed Management Task Force, Inc. (DMTF). All rights reserved. 12 DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems 13 management and interoperability. Members and non-members may reproduce DMTF specifications and 14 documents, provided that correct attribution is given. As DMTF specifications may be revised from time to 15 time, the particular version and release date should always be noted. 16 Implementation of certain elements of this standard or proposed standard may be subject to third party 17 patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations 18 to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose, 19 or identify any or all such third party patent right, owners or claimants, nor for any incomplete or 20 inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to 21 any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize, 22 disclose, or identify any such third party patent rights, or for such party’s reliance on the standard or 23 incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any 24 party implementing such standard, whether such implementation is foreseeable or not, nor to any patent 25 owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is 26 withdrawn or modified after publication, and shall be indemnified and held harmless by any party 27 implementing the standard from any and all claims of infringement by a patent owner for such 28 implementations. 2 DMTF Standard Version 1.0.0
  • 3. DSP0243 Open Virtualization Format Specification 29 CONTENTS 30 Foreword ....................................................................................................................................................... 5 31 Introduction ................................................................................................................................................... 6 32 1 Scope .................................................................................................................................................... 7 33 2 Normative References........................................................................................................................... 7 34 2.1 Approved References ................................................................................................................. 7 35 2.2 Other References........................................................................................................................ 8 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............................................................................................................... 18 50 8.1 VirtualHardwareSection ............................................................................................................ 18 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................................................................................................................................... 37 69 ANNEX A (informative) Symbols and Conventions ................................................................................... 39 70 ANNEX B (informative) Change Log.......................................................................................................... 40 71 ANNEX C (normative) OVF XSD ............................................................................................................... 41 72 Version 1.0.0 DMTF Standard 3
  • 4. Open Virtualization Format Specification DSP0243 73 Tables 74 Table 1 – XML Namespace Prefixes .......................................................................................................... 14 75 Table 2 – Actions for Child Elements with ovf:required Attribute......................................................... 20 76 Table 3 – HostResource Element ............................................................................................................... 21 77 Table 4 – Elements for Virtual Devices and Controllers ............................................................................. 22 78 Table 5 – Core Metadata Sections ............................................................................................................. 24 79 Table 6 – Property Types............................................................................................................................ 29 80 Table 7 – Property Qualifiers ...................................................................................................................... 30 81 Table 8 – Core Sections.............................................................................................................................. 37 82 4 DMTF Standard Version 1.0.0
  • 5. DSP0243 Open Virtualization Format Specification 83 Foreword 84 The Open Virtualization Format Specification (DSP0243) was prepared by the DMTF System 85 Virtualization, Partitioning, and Clustering Working Group. 86 This specification has been developed as a result of joint work with many individuals and teams, 87 including: 88 Simon Crosby, XenSource 89 Ron Doyle, IBM 90 Mike Gering, IBM 91 Michael Gionfriddo, Sun Microsystems 92 Steffen Grarup, VMware (Co-Editor) 93 Steve Hand, Symantec 94 Mark Hapner, Sun Microsystems 95 Daniel Hiltgen, VMware 96 Michael Johanssen, IBM 97 Lawrence J. Lamers, VMware (Chair) 98 John Leung, Intel Corporation 99 Fumio Machida, NEC Corporation 100 Andreas Maier, IBM 101 Ewan Mellor, XenSource 102 John Parchem, Microsoft 103 Shishir Pardikar, XenSource 104 Stephen J. Schmidt, IBM 105 René W. Schmidt, VMware (Co-Editor) 106 Andrew Warfield, XenSource 107 Mark D. Weitzel, IBM 108 John Wilson, Dell Version 1.0.0 DMTF Standard 5
  • 6. Open Virtualization Format Specification DSP0243 109 Introduction 110 The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and 111 extensible format for the packaging and distribution of software to be run in virtual machines. The key 112 properties of the format are as follows: 113 • Optimized for distribution 114 OVF supports content verification and integrity checking based on industry-standard public key 115 infrastructure, and it provides a basic scheme for management of software licensing. 116 • Optimized for a simple, automated user experience 117 OVF supports validation of the entire package and each virtual machine or metadata 118 component of the OVF during the installation phases of the virtual machine (VM) lifecycle 119 management process. It also packages with the package relevant user-readable descriptive 120 information that a virtualization platform can use to streamline the installation experience. 121 • Supports both single VM and multiple-VM configurations 122 OVF supports both standard single VM packages and packages containing complex, multi-tier 123 services consisting of multiple interdependent VMs. 124 • Portable VM packaging 125 OVF is virtualization platform neutral, while also enabling platform-specific enhancements to be 126 captured. It supports the full range of virtual hard disk formats used for hypervisors today, and it 127 is extensible, which allow it to accommodate formats that may arise in the future. Virtual 128 machine properties are captured concisely and accurately. 129 • Vendor and platform independent 130 OVF does not rely on the use of a specific host platform, virtualization platform, or guest 131 operating system. 132 • Extensible 133 OVF is immediately useful — and extensible. It is designed to be extended as the industry 134 moves forward with virtual appliance technology. It also supports and permits the encoding of 135 vendor-specific metadata to support specific vertical markets. 136 • Localizable 137 OVF supports user-visible descriptions in multiple locales, and it supports localization of the 138 interactive processes during installation of an appliance. This capability allows a single 139 packaged appliance to serve multiple market opportunities. 140 • Open standard 141 OVF has arisen from the collaboration of key vendors in the industry, and it is developed in an 142 accepted industry forum as a future standard for portable virtual machines. 143 It is not an explicit goal for OVF to be an efficient execution format. A hypervisor is allowed but not 144 required to run software in virtual machines directly out of the Open Virtualization Format. 145 6 DMTF Standard Version 1.0.0
  • 7. DSP0243 Open Virtualization Format Specification 146 Open Virtualization Format Specification 147 1 Scope 148 The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and 149 extensible format for the packaging and distribution of software to be run in virtual machines. 150 2 Normative References 151 The following referenced documents are indispensable for the application of this document. For dated 152 references, only the edition cited applies. For undated references, the latest edition of the referenced 153 document (including any amendments) applies. 154 2.1 Approved References 155 ANSI/IEEE Standard 1003.1-2001, IEEE Standard for Information Technology- Portable Operating 156 System Interface (POSIX), Institute of Electrical and Electronics Engineers, August 2001, 157 http://ieeexplore.ieee.org/xpl/tocresult.jsp?isNumber=1316 158 DMTF DSP0004, Common Information Model (CIM) Infrastructure Specification, 159 http://www.dmtf.org/standards/published_documents/DSP0004V2.3_final.pdf 160 DMTF DSP1043, Allocation Capabilities Profile (ACP), 161 http://www.dmtf.org/standards/published_documents/DSP1043.pdf 162 DMTF CIM Schema Version 2.19 (MOF files), 163 http://www.dmtf.org/standards/cim/cim_schema_v219 164 DMTF DSP1041, Resource Allocation Profile (RAP), 165 http://www.dmtf.org/standards/published_documents/DSP1041.pdf 166 DMTF DSP1042, System Virtualization Profile (SVP), 167 http://www.dmtf.org/standards/published_documents/DSP1042.pdf 168 DMTF DSP1057, Virtual System Profile (VSP), 169 http://www.dmtf.org/standards/published_documents/DSP1057.pdf 170 DMTF DSP0230, WS-CIM Mapping Specification, 171 http://www.dmtf.org/standards/published_documents/DSP0230.pdf 172 IETF RFC 1738, T. Berners-Lee, Uniform Resource Locators (URL), December 1994, 173 http://www.ietf.org/rfc/rfc1738.txt 174 IETF RFC1952, P. Deutsch, GZIP file format specification version 4.3, May 1996, 175 http://www.ietf.org/rfc/rfc1952.txt 176 IETF RFC 2234, Augmented BNF (ABNF), 177 http://www.ietf.org/rfc/rfc2234.txt 178 IETF RFC 2616, R. Fielding et al, Hypertext Transfer Protocol – HTTP/1.1, June 1999, 179 http://www.ietf.org/rfc/rfc2616.txt 180 IETF RFC 2818, E. Rescorla, HTTP over TLS, May 2000, 181 http://www.ietf.org/rfc/rfc2818.txt Version 1.0.0 DMTF Standard 7
  • 8. Open Virtualization Format Specification DSP0243 182 IETF RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, 183 http://www.ietf.org/rfc/rfc3986.txt 184 ISO 9660, 1988 Information processing-Volume and file structure of CD-ROM for information interchange, 185 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=17505 186 2.2 Other References 187 ISO, ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards, 188 http://isotc.iso.org/livelink/livelink.exe?func=ll&objId=4230456&objAction=browse&sort=subtype 189 W3C, Y. Savourel et al, Best Practices for XML Internationalization, Working Draft, October 2007, 190 http://www.w3.org/TR/2007/WD-xml-i18n-bp-20071031 191 3 Terms and Definitions 192 For the purposes of this document, the following terms and definitions apply. 193 3.1 194 can 195 used for statements of possibility and capability, whether material, physical, or causal 196 3.2 197 cannot 198 used for statements of possibility and capability, whether material, physical, or causal 199 3.3 200 conditional 201 indicates requirements to be followed strictly to conform to the document when the specified conditions 202 are met 203 3.4 204 mandatory 205 indicates requirements to be followed strictly to conform to the document and from which no deviation is 206 permitted 207 3.5 208 may 209 indicates a course of action permissible within the limits of the document 210 3.6 211 need not 212 indicates a course of action permissible within the limits of the document 213 3.7 214 optional 215 indicates a course of action permissible within the limits of the document 216 3.8 217 shall 218 indicates requirements to be followed strictly to conform to the document and from which no deviation is 219 permitted 8 DMTF Standard Version 1.0.0
  • 9. DSP0243 Open Virtualization Format Specification 220 3.9 221 shall not 222 indicates requirements to be followed strictly to conform to the document and from which no deviation is 223 permitted 224 3.10 225 should 226 indicates that among several possibilities, one is recommended as particularly suitable, without 227 mentioning or excluding others, or that a certain course of action is preferred but not necessarily required 228 3.11 229 should not 230 indicates that a certain possibility or course of action is deprecated but not prohibited 231 3.12 232 appliance 233 see virtual appliance 234 3.13 235 deployment platform 236 the product that installs an OVF package 237 3.14 238 guest software 239 the software, stored on the virtual disks, that runs when a virtual machine is powered on 240 The guest is typically an operating system and some user-level applications and services. 241 3.15 242 OVF package 243 OVF XML descriptor file accompanied by zero or more files 244 3.16 245 OVF descriptor 246 OVF XML descriptor file 247 3.17 248 platform 249 see deployment platform 250 3.18 251 virtual appliance 252 a service delivered as a complete software stack installed on one or more virtual machines 253 A virtual appliance is typically expected to be delivered in an OVF package. 254 3.19 255 virtual hardware 256 the hardware (including the CPU, controllers, Ethernet devices, and disks) that is seen by the guest 257 software 258 3.20 259 virtual machine 260 the complete environment that supports the execution of guest software 261 A virtual machine is a full encapsulation of the virtual hardware, virtual disks, and the metadata Version 1.0.0 DMTF Standard 9
  • 10. Open Virtualization Format Specification DSP0243 262 associated with it. Virtual machines allow multiplexing of the underlying physical machine through a 263 software layer called a hypervisor. 264 3.21 265 virtual machine collection 266 a service comprised of a set of virtual machines 267 The service can be a simple set of one or more virtual machines, or it can be a complex service built out 268 of a combination of virtual machines and other virtual machine collections. Because virtual machine 269 collections can be composed, it enables complex nested components. 270 4 Symbols and Abbreviated Terms 271 The following symbols and abbreviations are used in this document. 272 4.1 273 CIM 274 Common Information Model 275 4.2 276 IP 277 Internet Protocol 278 4.3 279 OVF 280 Open Virtualization Format 281 4.4 282 VM 283 Virtual Machine 284 5 OVF Packages 285 5.1 OVF Package Structure 286 An OVF package shall consist of the following files: 287 • one OVF descriptor with extension .ovf 288 • zero or one OVF manifest with extension .mf 289 • zero or one OVF certificate with extension .cert 290 • zero or more disk image files 291 • zero or more additional resource files, such as ISO images 292 The file extensions .ovf, .mf and .cert shall be used. 293 EXAMPLE 1: The following list of files is an example of an OVF package. 294 package.ovf 295 package.mf 296 de-DE-resources.xml 10 DMTF Standard Version 1.0.0
  • 11. DSP0243 Open Virtualization Format Specification 297 vmdisk1.vmdk 298 vmdisk2.vmdk 299 resource.iso 300 NOTE: The previous example uses VMDK disk files, but multiple disk formats are supported. 301 An OVF package can be stored as either a single unit or a set of files, see clause 5.3 and 5.4. Both 302 modes shall be supported. 303 Optionally, an OVF package may have a manifest file with extension .mf containing the SHA-1 digests of 304 individual files in the package. The manifest file shall have the same base name as the .ovf file. If the 305 manifest file is present, a consumer of the OVF package shall verify the digests by computing the actual 306 SHA-1 digests and comparing them with the digests listed in the manifest file. 307 The syntax definitions below use ABNF with the exceptions listed in ANNEX A. 308 The format of the .mf file is as follows: 309 manifest_file = *( file_digest ) 310 file_digest = algorithm "(" file_name ")" "=" sp digest nl 311 algorithm = "SHA1" 312 digest = 40( hex-digit ) ; 160-bit digest in 40-digit hexadecimal 313 hex-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | 314 "b" | "c" | "d" | "e" | "f" 315 sp = %x20 316 nl = %x0A 317 EXAMPLE 2: The following example show the partial contents of a manifest file. 318 SHA1(package.ovf)= 237de026fb285b85528901da058475e56034da95 319 SHA1(vmdisk1.vmdk)= 393a66df214e192ffbfedb78528b5be75cc9e1c3 320 An OVF package may be signed by signing the manifest file. The digest of the manifest file is stored in a 321 .cert file along with the base64-encoded X.509 certificate. The .cert file shall have the same base name 322 as the OVF descriptor. A consumer of the OVF package shall verify the signature and should validate the 323 certificate. The format of the .cert file shall be: 324 certificate_file = manifest_digest certificate_part 325 manifest_digest = algorithm "(" file_name ")" "=" sp signed_digest nl 326 algorithm = "SHA1" 327 signed_digest = *( hex-digit) 328 certificate_part = certificate_header certificate_body certificate_footer 329 certificate_header = "-----BEGIN CERTIFICATE-----" nl 330 certificate_footer = "-----END CERTIFICATE-----" nl 331 certificate_body = base64-encoded-certificate nl 332 ; base64-encoded-certificate is a base64-encoded X.509 333 ; certificate, which may be split across multiple lines 334 hex-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" 335 | "b" | "c" | "d" | "e" | "f" 336 sp = %x20 337 nl = %x0A 338 EXAMPLE 3: The following list of files is an example of a signed OVF package. Version 1.0.0 DMTF Standard 11
  • 12. Open Virtualization Format Specification DSP0243 339 package.ovf 340 package.mf 341 package.cert 342 de-DE-resources.xml 343 vmdisk1.vmdk 344 vmdisk2.vmdk 345 resource.iso 346 EXAMPLE 4: The following example shows the contents of a sample OVF certification file: 347 SHA1(package.mf)= 7f4b8efb8fe20c06df1db68281a63f1b088e19dbf00e5af9db5e8e3e319de 348 7019db88a3bc699bab6ccd9e09171e21e88ee20b5255cec3fc28350613b2c529089 349 -----BEGIN CERTIFICATE----- 350 MIIBgjCCASwCAQQwDQYJKoZIhvcNAQEEBQAwODELMAkGA1UEBhMCQVUxDDAKBgNV 351 BAgTA1FMRDEbMBkGA1UEAxMSU1NMZWF5L3JzYSB0ZXN0IENBMB4XDTk1MTAwOTIz 352 MzIwNVoXDTk4MDcwNTIzMzIwNVowYDELMAkGA1UEBhMCQVUxDDAKBgNVBAgTA1FM 353 RDEZMBcGA1UEChMQTWluY29tIFB0eS4gTHRkLjELMAkGA1UECxMCQ1MxGzAZBgNV 354 BAMTElNTTGVheSBkZW1vIHNlcnZlcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC3 355 LCXcScWua0PFLkHBLm2VejqpA1F4RQ8q0VjRiPafjx/Z/aWH3ipdMVvuJGa/wFXb 356 /nDFLDlfWp+oCPwhBtVPAgMBAAEwDQYJKoZIhvcNAQEEBQADQQArNFsihWIjBzb0 357 DCsU0BvL2bvSwJrPEqFlkDq3F4M6EGutL9axEcANWgbbEdAvNJD1dmEmoWny27Pn 358 IMs6ZOZB 359 -----END CERTIFICATE----- 360 5.2 Virtual Disk Formats 361 OVF does not require any specific disk format to be used, but to comply with this specification the disk 362 format shall be given by a URI which identifies an unencumbered specification on how to interpret the 363 disk format. The specification need not be machine readable, but it shall be static and unique so that the 364 URI may be used as a key by software reading an OVF package to uniquely determine the format of the 365 disk. The specification shall provide sufficient information so that a skilled person can properly interpret 366 the disk format for both reading and writing of disk data. It is recommended that these URIs are 367 resolvable. 368 5.3 Distribution as a Single File 369 An OVF package may be stored as a single file using the TAR format. The extension of that file shall be 370 .ova (open virtual appliance or application). 371 EXAMPLE: The following example shows a sample filename for an OVF package of this type: 372 D:virtualappliancesmyapp.ova 373 For OVF packages stored as single file, all file references in the OVF descriptor shall be relative-path 374 references and shall point to files included in the TAR archive. Relative directories inside the archive are 375 allowed, but relative-path references shall not contain ".." dot-segments. 376 Ordinarily, a TAR extraction tool would have to scan the whole archive, even if the file requested is found 377 at the beginning, because replacement files can be appended without modifying the rest of the archive. 378 For OVF TAR files, duplication is not allowed within the archive. In addition, the files shall be in the 379 following order inside the archive: 380 1) .ovf descriptor 381 2) .mf manifest (optional) 382 3) .cert certificate (optional) 12 DMTF Standard Version 1.0.0
  • 13. DSP0243 Open Virtualization Format Specification 383 4) The remaining files shall be in the same order as listed in the References section (see 7.1). 384 Note that any external string resource bundle files for internationalization shall be first in the 385 References section (see clause 10). 386 5) .mf manifest (optional) 387 6) .cert certificate (optional) 388 Note that the certificate file is optional. If no certificate file is present, the manifest file is also optional. If 389 the manifest or certificate files are present, they shall either both be placed after the OVF descriptor, or 390 both be placed at the end of the archive. 391 For deployment, the ordering restriction ensures that it is possible to extract the OVF descriptor from an 392 OVF TAR file without scanning the entire archive. For generation, the ordering restriction ensures that an 393 OVF TAR file can easily be generated on-the-fly. The restrictions do not prevent OVF TAR files from 394 being created using standard TAR packaging tools. 395 The TAR format used shall comply with the USTAR (Uniform Standard Tape Archive) format as defined 396 by the POSIX IEEE 1003.1 standards group. 397 5.4 Distribution as a Set of Files 398 An OVF package can be made available as a set of files, for example on a standard Web server. 399 EXAMPLE: An example of an OVF package as a set of files on Web server follows: 400 http://mywebsite/virtualappliances/package.ovf 401 http://mywebsite/virtualappliances/vmdisk1.vmdk 402 http://mywebsite/virtualappliances/vmdisk2.vmdk 403 http://mywebsite/virtualappliances/resource.iso 404 http://mywebsite/virtualappliances/de-DE-resources.xml 405 6 OVF Descriptor 406 All metadata about the package and its contents is stored in the OVF descriptor. This is an extensible 407 XML document for encoding information, such as product details, virtual hardware requirements, and 408 licensing. 409 The ovf-envelope.xsd XML schema definition file for the OVF descriptor contains the elements and 410 attributes. 411 Clauses 7, 8, and 9, describe the semantics, structure, and extensibility framework of the OVF descriptor. 412 These clauses are not a replacement for reading the schema definitions, but they complement the 413 schema definitions. 414 The XML document of an OVF descriptor shall contain one Envelope element, which is the only element 415 allowed at the top level. 416 The XML namespaces used in this specification are listed in Table 1. The choice of any namespace prefix 417 is arbitrary and not semantically significant. Version 1.0.0 DMTF Standard 13
  • 14. Open Virtualization Format Specification DSP0243 418 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 419 7 Envelope Element 420 The Envelope element describes all metadata for the virtual machines (including virtual hardware), as 421 well as the structure of the OVF package itself. 422 The outermost level of the envelope consists of the following parts: 423 • A version indication, defined by the XML namespace URIs. 424 • A list of file references to all external files that are part of the OVF package, defined by the 425 References element and its File child elements. These are typically virtual disk files, ISO 426 images, and internationalization resources. 427 • A metadata part, defined by section elements, as defined in clause 9. 428 • A description of the content, either a single virtual machine (VirtualSystem element) or a 429 collection of multiple virtual machines (VirtualSystemCollection element). 430 • A specification of message resource bundles for zero or more locales, defined by a Strings 431 element for each locale. 432 EXAMPLE: An example of the structure of an OVF descriptor with the top level Envelope element follows: 433 <?xml version="1.0" encoding="UTF-8"?> 434 <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 435 xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim- 436 schema/2/CIM_VirtualSystemSettingData" 437 xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim- 438 schema/2/CIM_ResourceAllocationSettingData" 439 xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" 440 xmlns="http://schemas.dmtf.org/ovf/envelope/1" 441 xml:lang="en-US"> 442 <References> 443 <File ovf:id="de-DE-resources.xml" ovf:size="15240" 444 ovf:href="http://mywebsite/virtualappliances/de-DE-resources.xml"/> 445 <File ovf:id="file1" ovf:href="vmdisk1.vmdk" ovf:size="180114671"/> 446 <File ovf:id="file2" ovf:href="vmdisk2.vmdk" ovf:size="4882023564" 447 ovf:chunkSize="2147483648"/> 448 <File ovf:id="file3" ovf:href="resource.iso" ovf:size="212148764" 449 ovf:compression="gzip"/> 450 <File ovf:id="icon" ovf:href="icon.png" ovf:size="1360"/> 451 </References> 452 <!-- Describes meta-information about all virtual disks in the package --> 453 <DiskSection> 454 <Info>Describes the set of virtual disks</Info> 455 <!-- Additional section content --> 14 DMTF Standard Version 1.0.0
  • 15. DSP0243 Open Virtualization Format Specification 456 </DiskSection> 457 <!-- Describes all networks used in the package --> 458 <NetworkSection> 459 <Info>List of logical networks used in the package</Info> 460 <!-- Additional section content --> 461 </NetworkSection> 462 <SomeSection ovf:required="false"> 463 <Info>A plain-text description of the content</Info> 464 <!-- Additional section content --> 465 </SomeSection> 466 <!-- Additional sections can follow --> 467 <VirtualSystemCollection ovf:id="Some Product"> 468 <!-- Additional sections including VirtualSystem or VirtualSystemCollection--> 469 </VirtualSystemCollection > 470 <Strings xml:lang="de-DE"> 471 <!-- Specification of message resource bundles for de-DE locale --> 472 </Strings> 473 </Envelope> 474 The optional xml:lang attribute on the Envelope element shall specify the default locale for messages 475 in the descriptor. The optional Strings elements shall contain message resource bundles for different 476 locales. See clause 10 for more details on internationalization support. 477 7.1 File References 478 The file reference part defined by the References element allows a tool to easily determine the integrity 479 of an OVF package without having to parse or interpret the entire structure of the descriptor. Tools can 480 safely manipulate (for example, copy or archive) OVF packages with no risk of losing files. 481 External string resource bundle files for internationalization shall be placed first in the References 482 element, see clause 10 for details. 483 Each File element in the reference part shall be given an identifier using the ovf:id attribute. The 484 identifier shall be unique inside an OVF package. Each File element shall be specified using the 485 ovf:href attribute, which shall contain a URL. Relative-path references and the URL schemes "file", 486 "http", and "https" shall be supported. Other URL schemes should not be used. If no URL scheme is 487 specified, the value of the ovf:href attribute shall be interpreted as a path name of the referenced file 488 that is relative to the location of the OVF descriptor itself. The relative path name shall use the syntax of 489 relative-path references in IEFT RFC3986. The referenced file shall exist. Two different File elements 490 shall not reference the same file with their ovf:href attributes. 491 The size of the referenced file may be specified using the ovf:size attribute. The unit of this attribute is 492 always bytes. 493 Each file referenced by a File element may be compressed using gzip (see RFC1952). When a File 494 element is compressed using gzip, the ovf:compression attribute shall be set to “gzip”. Otherwise, 495 the ovf:compression attribute shall be set to “identity” or the entire attribute omitted. Alternatively, 496 if the href is an HTTP or HTTPS URL, then the compression may be specified by the HTTP server by 497 using the HTTP header Content-Encoding: gzip (see RFC2616). Using HTTP content encoding in 498 combination with the ovf:compression attribute is allowed, but in general does not improve the 499 compression ratio. 500 Files referenced from the reference part may be split into chunks to accommodate file size restrictions on 501 certain file systems. Chunking shall be indicated by the presence of the ovf:chunkSize attribute; the 502 value of ovf:chunkSize shall be the size of each chunk, except the last chunk, which may be smaller. Version 1.0.0 DMTF Standard 15
  • 16. Open Virtualization Format Specification DSP0243 503 When ovf:chunkSize is specified, the File element shall reference a chunk file representing a chunk 504 of the entire file. In this case, the value of the ovf:href attribute specifies only a part of the URL and the 505 syntax for the URL resolving to the chunk file is given below. The syntax use ABNF with the exceptions 506 listed in ANNEX A. 507 chunk-url = href-value "." chunk-number 508 chunk-number = 9(decimal-digit) 509 decimal-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 510 where href-value is the value of the ovf:href attribute, and chunk-number is the 0-based position of the 511 chunk starting with the value 0 and increases with increments of 1 for each chunk. 512 Chunking can be combined with compression, the entire file is then compressed before chunking and 513 each chunk shall be an equal slice of the compressed file, except for the last chunk which may be 514 smaller. 515 7.2 Content Element 516 Virtual machine configurations in an OVF package are represented by a VirtualSystem or 517 VirtualSystemCollection element. These elements shall be given an identifier using the ovf:id 518 attribute. Direct child elements of a VirtualSystemCollection shall have unique identifiers. 519 In the OVF schema, the VirtualSystem and VirtualSystemCollection elements are part of a 520 substitution group with the Content element as head of the substitution group. The Content element is 521 abstract and cannot be used directly. The OVF descriptor shall have one or more Content elements. 522 The VirtualSystem element describes a single virtual machine and is simply a container of section 523 elements. These section elements describe virtual hardware, resources, and product information and are 524 described in detail in clauses 8 and 9. 525 The structure of a VirtualSystem element is as follows: 526 <VirtualSystem ovf:id="simple-app"> 527 <Info>A virtual machine</Info> 528 <Name>Simple Appliance</Name> 529 <SomeSection> 530 <!-- Additional section content --> 531 </SomeSection> 532 <!-- Additional sections can follow --> 533 </VirtualSystem> 534 The VirtualSystemCollection element is a container of multiple VirtualSystem or 535 VirtualSystemCollection elements. Thus, arbitrary complex configurations can be described. The 536 section elements at the VirtualSystemCollection level describe appliance information, properties, 537 resource requirements, and so on, and are described in detail in clause 9. 538 The structure of a VirtualSystemCollection element is as follows: 539 <VirtualSystemCollection ovf:id="multi-tier-app"> 540 <Info>A collection of virtual machines</Info> 541 <Name>Multi-tiered Appliance</Name> 542 <SomeSection> 543 <!-- Additional section content --> 544 </SomeSection> 545 <!-- Additional sections can follow --> 546 <VirtualSystem ovf:id="..."> 16 DMTF Standard Version 1.0.0
  • 17. DSP0243 Open Virtualization Format Specification 547 <!-- Additional sections --> 548 </VirtualSystem> 549 <!-- Additional VirtualSystem or VirtualSystemCollection elements can follow--> 550 </VirtualSystemCollection> 551 All elements in the Content substitution group shall contain an Info element and may contain a Name 552 element. The Info element contains a human readable description of the meaning of this entity. The 553 Name element is an optional localizable display name of the content. See clause 10 for details on how to 554 localize the Info and Name element. 555 7.3 Extensibility 556 This specification allows custom meta-data to be added to OVF descriptors in several ways: 557 • New section elements may be defined as part of the Section substitution group, and used 558 where the OVF schemas allow sections to be present. All subtypes of Section contain an Info 559 element that contains a human readable description of the meaning of this entity. The values of 560 Info elements can be used, for example, to give meaningful warnings to users when a section is 561 being skipped, even if the parser does not know anything about the section. See clause 10 for 562 details on how to localize the Info element. 563 • The OVF schemas use an open content model, where all existing types may be extended at the 564 end with additional elements. Extension points are declared in the OVF schemas with xs:any 565 declarations with namespace="##other". 566 • The OVF schemas allow additional attributes on existing types. 567 Custom extensions shall not use XML namespaces defined in this specification. This applies to both 568 custom elements and custom attributes. 569 On custom elements, a Boolean ovf:required attribute specifies whether the information in the 570 element is required for correct behavior or optional. If not specified, the ovf:required attribute defaults 571 to TRUE. A consumer of an OVF package that detects an extension that is required and that it does not 572 understand shall fail. 573 For known Section elements, if additional child elements that are not understood are found and the 574 value of their ovf:required attribute is TRUE, the consumer of the OVF package shall interpret the 575 entire section as one it does not understand. The check is not recursive; it applies only to the direct 576 children of the Section element. 577 This behavior ensures that older parsers reject newer OVF specifications, unless explicitly instructed not 578 to do so. 579 On custom attributes, the information in the attribute shall not be required for correct behavior. 580 EXAMPLE 1: 581 <!—- Optional custom section example --> 582 <otherns:IncidentTrackingSection ovf:required="false"> 583 <Info>Specifies information useful for incident tracking purposes</Info> 584 <BuildSystem>Acme Corporation Official Build System</BuildSystem> 585 <BuildNumber>102876</BuildNumber> 586 <BuildDate>10-10-2008</BuildDate> 587 </otherns:IncidentTrackingSection> Version 1.0.0 DMTF Standard 17
  • 18. Open Virtualization Format Specification DSP0243 588 EXAMPLE 2: 589 <!—- Open content example (extension of existing type) --> 590 <AnnotationSection> 591 <Info>Specifies an annotation for this virtual machine</Info> 592 <Annotation>This is an example of how a future element (Author) can still be 593 parsed by older clients</Annotation> 594 <!-- AnnotationSection extended with Author element --> 595 <otherns:Author ovf:required="false">John Smith</otherns:Author> 596 </AnnotationSection> 597 EXAMPLE 3: 598 <!—- Optional custom attribute example --> 599 <Network ovf:name="VM network" otherns:desiredCapacity="1 Gbit/s"> 600 <Description>The main network for VMs</Description> 601 </Network> 602 7.4 Conformance 603 This specification defines three conformance levels for OVF descriptors, with 1 being the highest level of 604 conformance: 605 • OVF descriptor uses only sections and elements and attributes that are defined in this 606 specification. 607 Conformance Level: 1. 608 • OVF descriptor uses custom sections or elements or attributes that are not defined in this 609 specification, and all such extensions are optional as defined in clause 7.3. 610 Conformance Level: 2. 611 • OVF descriptor uses custom sections or elements that are not defined in this specification and at 612 least one such extension is required as defined in clause 7.3. The definition of all required 613 extensions shall be publicly available in an open and unencumbered XML Schema. The complete 614 specification may be inclusive in the XML schema or available as a separate document. 615 Conformance Level: 3. 616 The use of conformance level 3 limits portability and should be avoided if at all possible. 617 The conformance level is not specified directly in the OVF descriptor but shall be determined by the 618 above rules. 619 8 Virtual Hardware Description 620 8.1 VirtualHardwareSection 621 Each VirtualSystem element may contain one or more VirtualHardwareSection elements, each of which 622 describes the virtual hardware required by the virtual system.The virtual hardware required by a virtual 623 machine is specified in VirtualHardwareSection elements. This specification supports abstract or 624 incomplete hardware descriptions in which only the major devices are described. The hypervisor is 625 allowed to create additional virtual hardware controllers and devices, as long as the required devices 626 listed in the descriptor are realized. 627 This virtual hardware description is based on the CIM classes CIM_VirtualSystemSettingData and 628 CIM_ResourceAllocationSettingData. The XML representation of the CIM model is based on the 629 WS-CIM mapping (DSP0230). 18 DMTF Standard Version 1.0.0
  • 19. DSP0243 Open Virtualization Format Specification 630 EXAMPLE: Example of VirtualHardwareSection: 631 <VirtualHardwareSection ovf:transport="iso"> 632 <Info>500Mb, 1 CPU, 1 disk, 1 nic virtual machine</Info> 633 <System> 634 <vssd:VirtualSystemType>vmx-4</vssd:VirtualSystemType> 635 </System> 636 <Item> 637 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 638 <rasd:Description>Memory Size</rasd:Description> 639 <rasd:ElementName>512 MB of memory</rasd:ElementName> 640 <rasd:InstanceID>2</rasd:InstanceID> 641 <rasd:ResourceType>4</rasd:ResourceType> 642 <rasd:VirtualQuantity>512</rasd:VirtualQuantity> 643 </Item> 644 <!-- Additional Item elements can follow --> 645 </VirtualHardwareSection> 646 A VirtualSystem element shall have a VirtualHardwareSection direct child element. 647 VirtualHardwareSection is disallowed as a direct child element of a VirtualSystemCollection 648 element and of an Envelope element. 649 Multiple VirtualHardwareSection element occurrences are allowed within a single VirtualSystem 650 element. The consumer of the OVF package should select the most appropriate virtual hardware 651 description for the particular virtualization platform. 652 The ovf:transport attribute specifies the types of transport mechanisms by which properties are 653 passed to the virtual machine in an OVF environment document. This attribute supports a pluggable and 654 extensible architecture for providing guest/platform communication mechanisms. Several transport types 655 may be specified separated by single space character. See subclause 9.5 for a description of properties 656 and clause 11 for a description of transport types and OVF environments. 657 The vssd:VirtualSystemType element specifies a virtual system type identifier, which is an 658 implementation defined string that uniquely identifies the type of the virtual system. For example, a virtual 659 system type identifier could be vmx-4 for VMware’s fourth-generation virtual hardware or xen-3 for Xen’s 660 third-generation virtual hardware. Zero or more virtual system type identifiers may be specified separated 661 by single space character. In order for the OVF virtual system to be deployable on a target platform, the 662 virtual machine on the target platform is should support at least one of the virtual system types identified 663 in the vssd:VirtualSystemType elements. The virtual system type identifiers specified in 664 vssd:VirtualSystemType elements are expected to be matched against the values of property 665 VirtualSystemTypesSupported of CIM class CIM_VirtualSystemManagementCapabilities (see DSP1042). 666 The virtual hardware characteristics are described as a sequence of Item elements. The Item element 667 is an XML representation of an instance of the CIM class CIM_ResourceAllocationSettingData. 668 The element can describe all memory and CPU requirements as well as virtual hardware devices. 669 Multiple device subtypes may be specified in an Item element, separated by single space character. 670 EXAMPLE: 671 <rasd:ResourceSubType>buslogic lsilogic</rasd:ResourceSubType> Version 1.0.0 DMTF Standard 19
  • 20. Open Virtualization Format Specification DSP0243 672 8.2 Extensibility 673 The optional ovf:required attribute on the Item element specifies whether the realization of the 674 element (for example, a CD-rom or USB controller) is required for correct behavior of the guest software. 675 If not specified, ovf:required defaults to TRUE. 676 On child elements of the Item element, the optional Boolean attribute ovf:required shall be 677 interpreted, even though these elements are in a different RASD WS-CIM namespace. A tool parsing an 678 Item element should act according to Table 2. 679 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 680 8.3 Virtual Hardware Elements 681 The general form of any Item element in a VirtualHardwareSection element is as follows: 682 <Item ovf:required="…" ovf:configuration="…" ovf:bound="…"> 683 <rasd:Address> ... </rasd:Address> 684 <rasd:AddressOnParent> ... </rasd:AddressOnParent> 685 <rasd:AllocationUnits> ... </rasd:AllocationUnits> 686 <rasd:AutomaticAllocation> ... </rasd:AutomaticAllocation> 687 <rasd:AutomaticDeallocation> ... </rasd:AutomaticDeallocation> 688 <rasd:Caption> ... </rasd:Caption> 689 <rasd:Connection> ... </rasd:Connection> 690 <!-- multiple connection elements can be specified --> 691 <rasd:ConsumerVisibility> ... </rasd:ConsumerVisibility> 692 <rasd:Description> ... </rasd:Description> 693 <rasd:ElementName> ... </rasd:ElementName> 694 <rasd:HostResource> ... </rasd:HostResource> 695 <rasd:InstanceID> ... </rasd:InstanceID> 696 <rasd:Limit> ... </rasd:Limit> 697 <rasd:MappingBehavior> ... </rasd:MappingBehavior> 698 <rasd:OtherResourceType> ... </rasd:OtherResourceType> 699 <rasd:Parent> ... </rasd:Parent> 700 <rasd:PoolID> ... </rasd:PoolID> 701 <rasd:Reservation> ... </rasd:Reservation> 702 <rasd:ResourceSubType> ... </rasd:ResourceSubType> 703 <rasd:ResourceType> ... </rasd:ResourceType> 704 <rasd:VirtualQuantity> ... </rasd:VirtualQuantity> 705 <rasd:Weight> ... </rasd:Weight> 706 </Item> 20 DMTF Standard Version 1.0.0
  • 21. DSP0243 Open Virtualization Format Specification 707 The elements represent the properties exposed by the CIM_ResourceAllocationSettingData 708 class. They have the semantics of defined settings as defined in DSP1041, any profiles derived from 709 DSP1041 for specific resource types, and this document. 710 EXAMPLE: The following example shows a description of memory size: 711 <Item> 712 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 713 <rasd:Description>Memory Size</rasd:Description> 714 <rasd:ElementName>256 MB of memory</rasd:ElementName> 715 <rasd:InstanceID>2</rasd:InstanceID> 716 <rasd:ResourceType>4</rasd:ResourceType> 717 <rasd:VirtualQuantity>256</rasd:VirtualQuantity> 718 </Item> 719 The Description element is used to provide additional metadata about the element itself. This element 720 enables a consumer of the OVF package to provide descriptive information about all items, including 721 items that were unknown at the time the application was written. 722 The Caption, Description and ElementName elements are localizable using the ovf:msgid 723 attribute from the OVF envelope namespace. See clause 10 for more details on internationalization 724 support. 725 The optional ovf:configuration attribute contains a list of configuration names. See clause 9.8 on 726 deployment options for semantics of this attribute. The optional ovf:bound attribute is used to specify 727 ranges, see subclause 8.4. 728 Devices such as disks, CD-ROMs, and networks need a backing from the deployment platform. The 729 requirements on a backing are either specified using the HostResource or the Connection element. 730 For an Ethernet adapter, a logical network name is specified in the Connection element. Ethernet 731 adapters that refer to the same logical network name within an OVF package shall be deployed on the 732 same network. 733 The HostResource element is used to refer to resources included in the OVF descriptor as well as 734 logical devices on the deployment platform. Values for HostResource elements referring to resources 735 included in the OVF descriptor are formatted as URIs as specified in Table 3. 736 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. 737 If no backing is specified for a device that requires a backing, the deployment platform shall make an 738 appropriate choice, for example, by prompting the user. Specifying more than one backing for a device is 739 not allowed. 740 Table 4 gives a brief overview on how elements are used to describe virtual devices and controllers. Version 1.0.0 DMTF Standard 21
  • 22. Open Virtualization Format Specification DSP0243 741 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. 742 Only fields directly related to describing devices are mentioned. Refer to the CIM MOF for a complete 743 description of all fields. 744 8.4 Ranges on Elements 745 The optional ovf:bound attribute may be used to specify ranges for the Item elements. A range has a 746 minimum, normal, and maximum value, denoted by min, normal, and max, where min <= normal <= 747 max. The default values for min and max are those specified for normal. 748 A platform deploying an OVF package is recommended to start with the normal value and adjust the 749 value within the range for ongoing performance tuning and validation. 750 For the Item elements in VirtualHardwareSection and ResourceAllocationSection elements, 751 the following additional semantics is defined: 752 • Each Item element has an optional ovf:bound attribute. This value may be specified as min, 753 max, or normal. The value defaults to normal. If the attribute is not specified or is specified as 754 normal, then the item is interpreted as being part of the regular virtual hardware or resource 755 allocation description. 22 DMTF Standard Version 1.0.0
  • 23. DSP0243 Open Virtualization Format Specification 756 • If the ovf:bound value is specified as either min or max, the item is used to specify the upper 757 or lower bound for one or more values for a given InstanceID. Such an item is called a range 758 marker. 759 The semantics of range markers are: 760 • InstanceID and ResourceType shall be specified, and the ResourceType shall match 761 other Item elements with the same InstanceID. 762 • Specifying more than one min range marker or more than one max range marker for a given 763 RASD (identified with InstanceID) is invalid. 764 • An Item element with a range marker shall have a corresponding Item element without a 765 range marker, that is, an Item element with no ovf:bound attribute or ovf:bound attribute 766 with value normal. This corresponding item specifies the default value. 767 • For an Item element where only a min range marker is specified, the max value is unbounded 768 upwards within the set of valid values for the property. 769 • For an Item where only a max range marker is specified, the min value is unbounded 770 downwards within the set of valid values for the property. 771 • The default value shall be inside the range. 772 • The use of non-integer elements in range marker RASDs is invalid. 773 EXAMPLE: The following example shows the use of range markers: 774 <VirtualHardwareSection> 775 <Info>...</Info> 776 <Item> 777 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 778 <rasd:ElementName>512 MB memory size</rasd:ElementName> 779 <rasd:InstanceID>0</rasd:InstanceID> 780 <rasd:ResourceType>4</rasd:ResourceType> 781 <rasd:VirtualQuantity>512</rasd:VirtualQuantity> 782 </Item> 783 <Item ovf:bound="min"> 784 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 785 <rasd:ElementName>384 MB minimum memory size</rasd:ElementName> 786 <rasd:InstanceID>0</rasd:InstanceID> 787 <rasd:Reservation>384</rasd:Reservation> 788 <rasd:ResourceType>4</rasd:ResourceType> 789 </Item> 790 <Item ovf:bound="max"> 791 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 792 <rasd:ElementName>1024 MB maximum memory size</rasd:ElementName> 793 <rasd:InstanceID>0</rasd:InstanceID> 794 <rasd:Reservation>1024</rasd:Reservation> 795 <rasd:ResourceType>4</rasd:ResourceType> 796 </Item> 797 </VirtualHardwareSection> Version 1.0.0 DMTF Standard 23
  • 24. Open Virtualization Format Specification DSP0243 798 9 Core Metadata Sections 799 Table 5 shows the core metadata sections that are defined. 800 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 VirtualSystemCollection product 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 VirtualSystemCollection package 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 801 The following subclauses describe the semantics of the core sections and provide some 802 examples. The sections are used in several places of an OVF envelope, the description of each 803 section defines where it may be used. See the OVF schema for a detailed specification of all 804 attributes and elements. 805 In the OVF schema, all sections are part of a substitution group with the Section element as head of the 806 substitution group. The Section element is abstract and cannot be used directly. 807 24 DMTF Standard Version 1.0.0
  • 25. DSP0243 Open Virtualization Format Specification 808 9.1 DiskSection 809 A DiskSection describes meta-information about virtual disks in the OVF package. Virtual disks 810 and their metadata are described outside the virtual hardware to facilitate sharing between virtual 811 machines within an OVF package. 812 EXAMPLE: The following example shows a description of virtual disks: 813 <DiskSection> 814 <Info>Describes the set of virtual disks</Info> 815 <Disk ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:capacity="8589934592" 816 ovf:populatedSize="3549324972" 817 ovf:format= 818 "http://www.vmware.com/interfaces/specifications/vmdk.html#sparse"> 819 </Disk> 820 <Disk ovf:diskId="vmdisk2" ovf:capacity="536870912" 821 </Disk> 822 <Disk ovf:diskId="vmdisk3" ovf:capacity="${disk.size}" 823 ovf:capacityAllocationUnits="byte * 2^30" 824 </Disk> 825 </DiskSection> 826 DiskSection is a valid section at the outermost envelope level only. 827 Each virtual disk is represented by a Disk element that shall be given a identifier using the ovf:diskId 828 attribute, the identifier shall be unique within the DiskSection. 829 The capacity of a virtual disk shall be specified by the ovf:capacity attribute with an xs:long integer 830 value. The default unit of allocation shall be bytes. The optional string attribute 831 ovf:capacityAllocationUnits may be used to specify a particular unit of allocation. Values for 832 ovf:capacityAllocationUnits shall match the format for programmatic units defined in DSP0004. 833 The ovf:fileRef attribute denotes the virtual disk content by identifying an existing File element in 834 the References element, the File element is identified by matching its ovf:id attribute value with the 835 ovf:fileRef attribute value. Omitting the ovf:fileRef attribute shall indicate an empty disk. In this 836 case, the disk shall be created and the entire disk content zeroed at installation time. The guest software 837 will typically format empty disks in some file system format. 838 The format URI (see clause 5.2) of a non-empty virtual disk shall be specified by the ovf:format 839 attribute. 840 Different Disk elements shall not contain ovf:fileRef attributes with identical values. Disk elements 841 shall be ordered such that they identify any File elements in the same order as these are defined in the 842 References element. 843 For empty disks, rather than specifying a fixed virtual disk capacity, the capacity for an empty disk may be 844 given using an OVF property, for example ovf:capacity="${disk.size}". The OVF property shall 845 resolve to an xs:long integer value. See 9.5 for a description of OVF properties. The 846 ovf:capacityAllocationUnits attribute is useful when using OVF properties because a user may 847 be prompted and can then enter disk sizing information in e.g. gigabytes. 848 For non-empty disks, the actual used size of the disk may optionally be specified using the 849 ovf:populatedSize attribute. The unit of this attribute is always bytes. ovf:populatedSize is 850 allowed to be an estimate of used disk size but shall not be larger than ovf:capacity. Version 1.0.0 DMTF Standard 25
  • 26. Open Virtualization Format Specification DSP0243 851 In VirtualHardwareSection, virtual disk devices may have a rasd:HostResource element 852 referring to a Disk element in DiskSection, see clause 8.3. The virtual disk capacity shall be defined 853 by the ovf:capacity attribute on the Disk element. If a rasd:VirtualQuantity element is 854 speficied along with the rasd:HostResource element, the virtual quantity value shall not be considered 855 and may have any value. 856 OVF allows a disk image to be represented as a set of modified blocks in comparison to a parent image. 857 The use of parent disks can often significantly reduce the size of an OVF package, if it contains multiple 858 disks with similar content. For a Disk element, a parent disk may optionally be specified using the 859 ovf:parentRef attribute, which shall contain a valid ovf:diskId reference to a different Disk 860 element. If a disk block does not exist locally, lookup for that disk block then occurs in the parent disk. In 861 DiskSection, parent Disk elements shall occur before child Disk elements that refer to them. 862 9.2 NetworkSection 863 The NetworkSection element shall list all logical networks used in the OVF package. 864 <NetworkSection> 865 <Info>List of logical networks used in the package</Info> 866 <Network ovf:name="red"> 867 <Description>The network the Red service is available on</Description> 868 </Network> 869 </NetworkSection> 870 NetworkSection is a valid element at the outermost envelope level. 871 All networks referred to from Connection elements in all VirtualHardwareSection elements shall 872 be defined in the NetworkSection. 873 9.3 ResourceAllocationSection 874 The ResourceAllocationSection element describes all resource allocation requirements of a 875 VirtualSystemCollection entity. These resource allocations shall be performed when deploying the 876 OVF package. 877 <ResourceAllocationSection> 878 <Info>Defines reservations for CPU and memory for the collection of VMs</Info> 879 <Item> 880 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 881 <rasd:ElementName>300 MB reservation</rasd:ElementName> 882 <rasd:InstanceID>0</rasd:InstanceID> 883 <rasd:Reservation>300</rasd:Reservation> 884 <rasd:ResourceType>4</rasd:ResourceType> 885 </Item> 886 <Item ovf:configuration="..." ovf:bound="..."> 887 <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> 888 <rasd:ElementName>500 MHz reservation</rasd:ElementName> 889 <rasd:InstanceID>0</rasd:InstanceID> 890 <rasd:Reservation>500</rasd:Reservation> 891 <rasd:ResourceType>3</rasd:ResourceType> 892 </Item> 893 </ResourceAllocationSection> 894 ResourceAllocationSection is a valid element for a VirtualSystemCollection entity. 26 DMTF Standard Version 1.0.0
  • 27. DSP0243 Open Virtualization Format Specification 895 The optional ovf:configuration attribute contains a list of configuration names. See 9.8 on 896 deployment options for semantics of this attribute. 897 The optional ovf:bound attribute contains a value of min, max, or normal. See 8.4 for semantics of this 898 attribute. 899 9.4 AnnotationSection 900 The AnnotationSection element is a user-defined annotation on an entity. Such annotations may be 901 displayed when deploying the OVF package. 902 <AnnotationSection> 903 <Info>An annotation on this service. It can be ignored</Info> 904 <Annotation>Contact customer support if you have any problems</Annotation> 905 </AnnotationSection > 906 AnnotationSection is a valid element for a VirtualSystem and a VirtualSystemCollection 907 entity. 908 See clause 10 for details on how to localize the Annotation element. 909 9.5 ProductSection 910 The ProductSection element specifies product-information for an appliance, such as product name, 911 version, and vendor. 912 <ProductSection ovf:class="com.mycrm.myservice" ovf:instance="1"> 913 <Info>Describes product information for the service</Info> 914 <Product>MyCRM Enterprise</Product> 915 <Vendor>MyCRM Corporation</Vendor> 916 <Version>4.5</Version> 917 <FullVersion>4.5-b4523</FullVersion> 918 <ProductUrl>http://www.mycrm.com/enterprise</ProductUrl> 919 <VendorUrl>http://www.mycrm.com</VendorUrl> 920 <Icon ovf:height="32" ovf:width="32" ovf:mimeType="image/png" ovf:fileRef="icon"> 921 <Category>Email properties</Category> 922 <Property ovf:key="admin.email" ovf:type="string" ovf:userConfigurable="true"> 923 <Label>Admin email</Label> 924 <Description>Email address of administrator</Description> 925 </Property> 926 <Category>Admin properties</Category> 927 <Property ovf:key="app.log" ovf:type="string" ovf:value="low" 928 ovf:userConfigurable="true"> 929 <Description>Loglevel for the service</Description> 930 </Property> 931 <Property ovf:key="app.isSecondary" ovf:value="false" ovf:type="boolean"> 932 <Description>Cluster setup for application server</Description> 933 </Property> 934 <Property ovf:key="app.ip" ovf:type="string" ovf:value="${appserver-vm}"> 935 <Description>IP address of the application server VM</Description> 936 </Property> 937 </ProductSection> Version 1.0.0 DMTF Standard 27
  • 28. Open Virtualization Format Specification DSP0243 938 The optional Product element specifies the name of the product, while the optional Vendor element 939 specifies the name of the product vendor. The optional Version element specifies the product version in 940 short form, while the optional FullVersion element describes the product version in long form. The 941 optional ProductUrl element specifies a URL which shall resolve to a human readable description of 942 the product, while the optional VendorUrl specifies a URL which shall resolve to a human readable 943 description of the vendor. 944 The optional AppUrl element specifies a URL resolving to the deployed product instance; this element is 945 experimental. The optional Icon element specifies display icons for the product; this element is 946 experimental. 947 Property elements specify application-level customization parameters and are particularly relevant to 948 appliances that need to be customized during deployment with specific settings such as network identity, 949 the IP addresses of DNS servers, gateways, and others. 950 ProductSection is a valid section for a VirtualSystem and a VirtualSystemCollection entity. 951 Property elements may be grouped by using Category elements. The set of Property elements 952 grouped by a Category element is the sequence of Property elements following the Category 953 element, until but not including an element that is not a Property element. For OVF packages 954 containing a large number of Property elements, this may provide a simpler installation experience. 955 Similarly, each Property element may have a short label defined by its Label child element in addition 956 to a description defined by its Description child element. See clause 10 for details on how to localize 957 the Category element and the Description and Label child elements of the Property element. 958 Each Property element in a ProductSection shall be given an identifier that is unique within the 959 ProductSection using the ovf:key attribute. 960 Each Property element in a ProductSection shall be given a type using the ovf:type attribute and 961 optionally type qualifiers using the ovf:qualifiers attribute. Valid types are listed in Table 6 and valid 962 qualifiers are listed in Table 7. 963 The optional attribute ovf:value is used to provide a default value for a property. One or more optional 964 Value elements may be used to define alternative default values for specific configurations, as defined in 965 clause 9.8. 966 The optional attribute ovf:userConfigurable determines whether the property value is configurable 967 during the installation phase. If ovf:userConfigurable is FALSE or omitted, the ovf:value attribute 968 specifies the value to be used for that customization parameter during installation. If 969 ovf:userConfigurable is TRUE, the ovf:value attribute specifies a default value for that 970 customization parameter, which may be changed during installation. 971 A simple OVF implementation such as a command-line installer typically uses default values for 972 properties and does not prompt even though ovf:userConfigurable is set to TRUE. To force 973 prompting at startup time, omitting the ovf:value attribute is sufficient for integer and IP types, because 974 the empty string is not a valid integer or IP value. For string types, prompting may be forced by using a 975 type for a non-empty string. 976 Zero or more ProductSections may be specified within a VirtualSystem or 977 VirtualSystemCollection. Typically, a ProductSection corresponds to a particular software 978 product that is installed. Each product section at the same entity level shall have a unique ovf:class 979 and ovf:instance attribute pair. For the common case where only a single ProductSection is used, 980 the ovf:class and ovf:instance attributes are optional and default to the empty string. It is 981 recommended that the ovf:class property be used to uniquely identify the software product using the 982 reverse domain name convention. Examples of values are com.vmware.tools and 28 DMTF Standard Version 1.0.0
  • 29. DSP0243 Open Virtualization Format Specification 983 org.apache.tomcat. If multiple instances of the same product are installed, the ovf:instance 984 attribute is used to identify the different instances. 985 Property elements are exposed to the guest software through the OVF environment, as described in 986 clause 11. The value of the ovfenv:key attribute of a Property element exposed in the OVF 987 environment shall be constructed from the value of the ovf:key attribute of the corresponding 988 Property element defined in a ProductSection entity of an OVF descriptor as follows: 989 key-value-env = [class-value "."] key-value-prod ["." instance-value] 990 where: 991 • class-value is the value of the ovf:class attribute of the Property element defined in the 992 ProductSection entity. The production [class-value "."] shall be present if and only if 993 class-value is not the empty string. 994 • key-value-prod is the value of the ovf:key attribute of the Property element defined in the 995 ProductSection entity. 996 • instance-value is the value of the ovf:instance attribute of the Property element defined in 997 the ProductSection entity. The production ["." instance-value] shall be present if and only 998 if instance-value is not the empty string. 999 EXAMPLE: The following OVF environment example shows how properties can be propagated to the guest 1000 software: 1001 <Property ovf:key="com.vmware.tools.logLevel" ovf:value="none"/> 1002 <Property ovf:key="org.apache.tomcat.logLevel.1" ovf:value="debug"/> 1003 <Property ovf:key="org.apache.tomcat.logLevel.2" ovf:value="normal"/> 1004 1005 The consumer of an OVF package should prompt for properties where ovf:userConfigurable is 1006 TRUE. These properties may be defined in multiple ProductSections as well as in sub-entities in the 1007 OVF package. 1008 The first ProductSection entity defined in the top-level Content element of a package shall define 1009 summary information that describes the entire package. After installation, a consumer of the OVF 1010 package could choose to make this information available as an instance of the CIM_Product class. 1011 Property elements specified on a VirtualSystemCollection are also seen by its immediate 1012 children (see clause 11). Children may refer to the properties of a parent VirtualSystemCollection 1013 using macros on the form ${name} as value for ovf:value attributes. 1014 Table 6 lists the valid types for properties. These are a subset of CIM intrinsic types defined in DSP0004, 1015 which also define the value space and format for each intrinsic type. Each Property element in a shall 1016 specify a type using the ovf:type attribute. 1017 Table 6 – Property Types Type Description uint8 Unsigned 8-bit integer sint8 Signed 8-bit integer uint16 Unsigned 16-bit integer sint16 Signed 16-bit integer uint32 Unsigned 32-bit integer sint32 Signed 32-bit integer Version 1.0.0 DMTF Standard 29
  • 30. Open Virtualization Format Specification DSP0243 Type Description uint64 Unsigned 64-bit integer sint64 Signed 64-bit integer string String boolean Boolean real32 IEEE 4-byte floating point real64 IEEE 8-byte floating point 1018 Table 7 lists the supported CIM type qualifiers as defined in DSP0004. Each Property element may 1019 optionally specify type qualifiers using the ovf:qualifiers attribute with multiple qualifiers separated 1020 by commas, see production qualifierList in ANNEX A “MOF Syntax Grammar Description” in 1021 DSP0004. 1022 Table 7 – Property Qualifiers Type Description string MinLen(min) MaxLen(max) ValueMap{...} uint8 ValueMap{...} sint8 uint16 sint16 uint32 sint32 uint64 sint64 1023 9.6 EulaSection 1024 A EulaSection contains the legal terms for using its parent Content element. This license shall be 1025 shown and accepted during deployment of an OVF package. Multiple EulaSections may be present in 1026 an OVF. If unattended installations are allowed, all embedded license sections are implicitly accepted. 1027 <EulaSection> 1028 <Info>Licensing agreement</Info> 1029 <License> 1030 Lorem ipsum dolor sit amet, ligula suspendisse nulla pretium, rhoncus tempor placerat 1031 fermentum, enim integer ad vestibulum volutpat. Nisl rhoncus turpis est, vel elit, 1032 congue wisi enim nunc ultricies sit, magna tincidunt. Maecenas aliquam maecenas ligula 1033 nostra, accumsan taciti. Sociis mauris in integer, a dolor netus non dui aliquet, 1034 sagittis felis sodales, dolor sociis mauris, vel eu libero cras. Interdum at. Eget 1035 habitasse elementum est, ipsum purus pede porttitor class, ut adipiscing, aliquet sed 1036 auctor, imperdiet arcu per diam dapibus libero duis. Enim eros in vel, volutpat nec 1037 pellentesque leo, scelerisque. 1038 </License> 1039 </EulaSection> 1040 EulaSection is a valid section for a VirtualSystem and a VirtualSystemCollection entity. 30 DMTF Standard Version 1.0.0
  • 31. DSP0243 Open Virtualization Format Specification 1041 See clause 10 for details on how to localize the License element. 1042 9.7 StartupSection 1043 The StartupSection specifies how a virtual machine collection is powered on and off. 1044 <StartupSection> 1045 <Item ovf:id="vm1" ovf:order="0" ovf:startDelay="30" ovf:stopDelay="0" 1046 ovf:startAction="powerOn" ovf:waitingForGuest="true" 1047 ovf:stopAction="powerOff"/> 1048 <Item ovf:id="teamA" ovf:order="0"/> 1049 <Item ovf:id="vm2" ovf:order="1" ovf:startDelay="0" ovf:stopDelay="20" 1050 ovf:startAction="powerOn" ovf:stopAction="guestShutdown"/> 1051 </StartupSection> 1052 Each Content element that is a direct child of a VirtualSystemCollection may have a 1053 corresponding Item element in the StartupSection entity of the VirtualSystemCollection entity. 1054 Note that Item elements may correspond to both VirtualSystem and VirtualSystemCollection 1055 entities. When a start or stop action is performed on a VirtualSystemCollection entity, the 1056 respective actions on the Item elements of its StartupSection entity are invoked in the specified 1057 order. Whenever an Item element corresponds to a (nested) VirtualSystemCollection entity, the 1058 actions on the Item elements of its StartupSection entity shall be invoked before the action on the 1059 Item element corresponding to that VirtualSystemCollection entity is invoked (i.e., depth-first 1060 traversal). 1061 The following required attributes on Item are supported for a VirtualSystem and 1062 VirtualSystemCollection: 1063 • ovf:id shall match the value of the ovf:id attribute of a Content element which is a direct 1064 child of this VirtualSystemCollection. That Content element describes the virtual 1065 machine or virtual machine collection to which the actions defined in the Item element apply. 1066 • ovf:order specifies the startup order using non-negative integer values. The order of 1067 execution of the start action is the numerical ascending order of the values. Items with same 1068 order identifier may be started up concurrently. The order of execution of the stop action is the 1069 numerical descending order of the values. 1070 The following optional attributes on Item are supported for a VirtualSystem. 1071 • ovf:startDelay specifies a delay in seconds to wait until proceeding to the next order in the 1072 start sequence. The default value is 0. 1073 • ovf:waitingForGuest enables the platform to resume the startup sequence after the guest 1074 software has reported it is ready. The interpretation of this is deployment platform specific. The 1075 default value is FALSE. 1076 • ovf:startAction specifies the start action to use. Valid values are powerOn and none. The 1077 default value is powerOn. 1078 • ovf:stopDelay specifies a delay in seconds to wait until proceeding to the previous order in 1079 the stop sequence. The default value is 0. 1080 • ovf:stopAction specifies the stop action to use. Valid values are powerOff, 1081 guestShutdown, and none. The interpretation of guestShutdown is deployment platform 1082 specific. The default value is powerOff. 1083 If not specified, an implicit default Item is created for each entity in the collection with ovf:order="0". 1084 Thus, for a trivial startup sequence no StartupSection needs to be specified. Version 1.0.0 DMTF Standard 31
  • 32. Open Virtualization Format Specification DSP0243 1085 9.8 DeploymentOptionSection 1086 The DeploymentOptionSection specifies a discrete set of intended resource configurations. The 1087 author of an OVF package can include sizing metadata for different configurations. A consumer of 1088 the OVF shall select a configuration, for example, by prompting the user. The selected 1089 configuration is visible in the OVF environment, enabling guest software to adapt to the selected 1090 configuration. See clause 11. 1091 The DeploymentOptionSection specifies an ID, label, and description for each configuration. 1092 <DeploymentOptionSection> 1093 <Configuration ovf:id="Minimal"> 1094 <Label>Minimal</Label> 1095 <Description>Some description</Description> 1096 </Configuration> 1097 <Configuration ovf:id="Typical" ovf:default="true"> 1098 <Label>Typical</Label> 1099 <Description>Some description</Description> 1100 </Configuration> 1101 <!-- Additional configurations --> 1102 </DeploymentOptionSection> 1103 The DeploymentOptionSection has the following semantics: 1104 • If present, the DeploymentOptionSection is valid only at the envelope level, and only one 1105 section shall be specified in an OVF descriptor. 1106 • The discrete set of configurations is described with Configuration elements, which 1107 shall have identifiers specified by the ovf:id attribute that are unique in the package. 1108 • A default Configuration element may be specified with the optional ovf:default 1109 attribute. If no default is specified, the first element in the list is the default. Specifying 1110 more than one element as the default is invalid. 1111 • The Label and Description elements are localizable using the ovf:msgid attribute. See 1112 clause 10 for more details on internationalization support. 1113 Configurations may be used to control resources for virtual hardware and for virtual machine 1114 collections. Item elements in VirtualHardwareSection elements describe resources for 1115 VirtualSystem entities, while Item elements in ResourceAllocationSection elements describe 1116 resources for virtual machine collections. For these two Item types, the following additional 1117 semantics are defined: 1118 Each Item has an optional ovf:configuration attribute, containing a list of configurations 1119 separated by a single space character. If not specified, the item shall be selected for any 1120 configuration. If specified, the item shall be selected only if the chosen configuration ID is in the 1121 list. A configuration attribute shall not contain an ID that is not specified in the 1122 DeploymentOptionSection. 1123 • Within a single VirtualHardwareSection or ResourceAllocationSection, multiple 1124 Item elements are allowed to refer to the same InstanceID. A single combined Item for 1125 the given InstanceID shall be constructed by picking up the child elements of each Item 1126 element, with child elements of a former Item element in the OVF descriptor not being 1127 picked up if there is a like-named child element in a latter Item element. Any attributes 1128 specified on child elements of Item elements that are not picked up that way, are not 1129 part of the combined Item element. 32 DMTF Standard Version 1.0.0
  • 33. DSP0243 Open Virtualization Format Specification 1130 • All Item elements shall specify ResourceType, and Item elements with the same 1131 InstanceID shall agree on ResourceType. 1132 EXAMPLE: The following example shows a VirtualHardwareSection: 1133 <VirtualHardwareSection> 1134 <Info>...</Info> 1135 <Item> 1136 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 1137 <rasd:ElementName>512 MB memory size and 256 MB 1138 reservation</rasd:ElementName> 1139 <rasd:InstanceID>0</rasd:InstanceID> 1140 <rasd:Reservation>256</rasd:Reservation> 1141 <rasd:ResourceType>4</rasd:ResourceType> 1142 <rasd:VirtualQuantity>512</rasd:VirtualQuantity> 1143 </Item> 1144 ... 1145 <Item ovf:configuration="big"> 1146 <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> 1147 <rasd:ElementName>1024 MB memory size and 512 MB 1148 reservation</rasd:ElementName> 1149 <rasd:InstanceID>0</rasd:InstanceID> 1150 <rasd:Reservation>512</rasd:Reservation> 1151 <rasd:ResourceType>4</rasd:ResourceType> 1152 <rasd:VirtualQuantity>1024</rasd:VirtualQuantity> 1153 </Item> 1154 </VirtualHardwareSection> 1155 Note that the attributes ovf:configuration and ovf:bound on Item may be used in combination to 1156 provide very flexible configuration options. 1157 Configurations can further be used to control default values for properties. For Property 1158 elements inside a ProductSection, the following additional semantic is defined: 1159 • It is possible to use alternative default property values for different configurations in a 1160 DeploymentOptionSection. In addition to a Label and Description element, each 1161 Property element may optionally contain Value elements. The Value element shall 1162 have an ovf:value attribute specifying the alternative default and an 1163 ovf:configuration attribute specifying the configuration in which this new default 1164 value should be used. Multiple Value elements shall not refer to the same 1165 configuration. 1166 EXAMPLE: The following shows an example ProductSection: 1167 <ProductSection> 1168 <Property ovf:key="app.log" ovf:type="string" ovf:value="low" 1169 ovf:userConfigurable="true"> 1170 <Label>Loglevel</Label> 1171 <Description>Loglevel for the service</Description> 1172 <Value ovf:value="none" ovf:configuration="minimal"> 1173 </Property> 1174 </ProductSection> Version 1.0.0 DMTF Standard 33
  • 34. Open Virtualization Format Specification DSP0243 1175 9.9 OperatingSystemSection 1176 An OperatingSystemSection specifies the operating system installed on a virtual machine. 1177 <OperatingSystemSection ovf:id="76"> 1178 <Info>Specifies the operating system installed</Info> 1179 <Description>Microsoft Windows Server 2008</Description> 1180 </OperatingSystemSection> 1181 The valid values for ovf:id are defined by the ValueMap qualifier in the 1182 CIM_OperatingSystem.OsType property. 1183 OperatingSystemSection is a valid section for a VirtualSystem entity only. 1184 9.10 InstallSection 1185 The InstallSection, if specified, indicates that the virtual machine needs to be booted once in order 1186 to install and/or configure the guest software. The guest software is expected to access the OVF 1187 environment during that boot, and to shut down after having completed the installation and/or 1188 configuration of the software, powering off the guest. 1189 If the InstallSection is not specified, this indicates that the virtual machine does not need to be 1190 powered on to complete installation of guest software. 1191 <InstallSection ovf:initialBootStopDelay="300"> 1192 <Info>Specifies that the virtual machine needs to be booted once after having 1193 created the guest software in order to install and/or configure the software 1194 </Info> 1195 </InstallSection> 1196 InstallSection is a valid section for a VirtualSystem entity only. 1197 The optional ovf:initialBootStopDelay attribute specifies a delay in seconds to wait for the virtual 1198 machine to power off. If not set, the implementation shall wait for the virtual machine to power off by itself. 1199 If the delay expires and the virtual machine has not powered off, the consumer of the OVF package shall 1200 indicate a failure. 1201 Note that the guest software in the virtual machine can do multiple reboots before powering off. 1202 Several VMs in a virtual machine collection may have an InstallSection defined, in which case the 1203 above step is done for each VM, potentially concurrently. 1204 10 Internationalization 1205 The following elements support localizable messages using the optional ovf:msgid attribute: 1206 • Info element on Content 1207 • Name element on Content 1208 • Info element on Section 1209 • Annotation element on AnnotationSection 1210 • License element on EulaSection 1211 • Description element on NetworkSection 1212 • Description element on OperatingSystemSection 34 DMTF Standard Version 1.0.0
  • 35. DSP0243 Open Virtualization Format Specification 1213 • Description, Product, Vendor, Label, and Category elements on ProductSection 1214 • Description and Label elements on DeploymentOptionSection 1215 • ElementName, Caption and Description subelements on the System element in 1216 VirtualHardwareSection 1217 • ElementName, Caption and Description subelements on Item elements in 1218 VirtualHardwareSection 1219 • ElementName, Caption and Description subelements on Item elements in 1220 ResourceAllocationSection 1221 The ovf:msgid attribute contains an identifier that refers to a message that may have different values in 1222 different locales. 1223 EXAMPLE 1: 1224 <Info ovf:msgid="info.text">Default info.text value if no locale is set or no locale 1225 match</Info> 1226 <License ovf:msgid="license.tomcat-6_0"/> <!-- No default message --> 1227 The optional xml:lang attribute on the Envelope element shall specify the default locale for messages 1228 in the descriptor. 1229 Message resource bundles can be internal or external to the OVF descriptor. Internal resource bundles 1230 are represented as Strings elements at the end of the Envelope element. 1231 EXAMPLE 2: 1232 <ovf:Envelope xml:lang="en-US"> 1233 ... 1234 ... sections and content here ... 1235 ... 1236 <Info msgid="info.os">Operating System</Info> 1237 ... 1238 <Strings xml:lang="da-DA"> 1239 <Msg ovf:msgid="info.os">Operativsystem</Msg> 1240 ... 1241 </Strings> 1242 <Strings xml:lang="de-DE"> 1243 <Msg ovf:msgid="info.os">Betriebssystem</Msg> 1244 ... 1245 </Strings> 1246 </ovf:Envelope> 1247 External resource bundles shall be listed first in the References section and referred to from Strings 1248 elements. An external message bundle follows the same schema as the embedded one. Exactly one 1249 Strings element shall be present in an external message bundle, and that Strings element may not 1250 have an ovf:fileRef attribute specified. 1251 EXAMPLE 3: 1252 <ovf:Envelope xml:lang="en-US"> 1253 <References> 1254 ... 1255 <File ovf:id="it-it-resources" ovf:href="resources/it-it-bundle.msg"/> 1256 </References> 1257 ... sections and content here ... 1258 ... Version 1.0.0 DMTF Standard 35
  • 36. Open Virtualization Format Specification DSP0243 1259 <Strings xml:lang="it-IT" ovf:fileRef="it-it-resources"/> 1260 ... 1261 </ovf:Envelope> 1262 EXAMPLE 4: Example content of external resources/it-it-bundle.msg file, which is referenced in previous example: 1263 <Strings 1264 xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" 1265 xmlns="http://schemas.dmtf.org/ovf/envelope/1" 1266 xml:lang="it-IT"> 1267 <Msg ovf:msgid="info.os">Sistema operativo</Msg> 1268 ... 1269 </Strings> 1270 The embedded and external Strings elements may be interleaved, but they shall be placed at the end 1271 of the Envelope element. If multiple occurrences of a msg:id attribute with a given locale occurs, a latter 1272 value overwrites a former. 1273 11 OVF Environment 1274 The OVF environment defines how the guest software and the deployment platform interact. This 1275 environment allows the guest software to access information about the deployment platform, such as the 1276 user-specified values for the properties defined in the OVF descriptor. 1277 The environment specification is split into a protocol part and a transport part. The protocol part defines 1278 the format and semantics of an XML document that can be made accessible to the guest software. The 1279 transport part defines how the information is communicated between the deployment platform and the 1280 guest software. 1281 The ovf-environment.xsd XML schema definition file for the OVF environment contains the elements 1282 and attributes. 1283 11.1 Environment Document 1284 The environment document is an extensible XML document that is provided to the guest software about 1285 the environment in which it is being executed. The way that the document is obtained depends on the 1286 transport type. 1287 EXAMPLE: An example of the structure of the OVF environment document follows: 1288 <?xml version="1.0" encoding="UTF-8"?> 1289 <Environment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 1290 xmlns:ovfenv="http://schemas.dmtf.org/ovf/environment/1" 1291 xmlns="http://schemas.dmtf.org/ovf/environment/1" 1292 ovfenv:id="identification of VM from OVF descriptor"> 1293 <!-- Information about virtualization platform --> 1294 <PlatformSection> 1295 <Kind>Type of virtualization platform</Kind> 1296 <Version>Version of virtualization platform</Version> 1297 <Vendor>Vendor of virtualization platform</Vendor> 1298 <Locale>Language and country code</Locale> 1299 <TimeZone>Current timezone offset in minutes from UTC</TimeZone> 1300 </PlatformSection> 1301 <!--- Properties defined for this virtual machine --> 1302 <PropertySection> 1303 <Property ovfenv:key="key" ovfenv:value="value"> 1304 <!-- More properties --> 36 DMTF Standard Version 1.0.0
  • 37. DSP0243 Open Virtualization Format Specification 1305 </PropertySection> 1306 <Entity ovfenv:id="id of sibling virtual system or virtual system collection"> 1307 <PropertySection> 1308 <!-- Properties from sibling --> 1309 </PropertySection> 1310 </Entity> 1311 </Environment> 1312 The PlatformSection element contains optional information provided by the deployment platform. 1313 Elements Kind, Version, and Vendor describe deployment platform vendor details, these elements are 1314 experimental. Elements Locale and TimeZone describe the current locale and time zone, these 1315 elements are experimental. 1316 The PropertySection element contains Property elements that correspond to those defined in the 1317 OVF descriptor for the current virtual machine. The environment presents properties as a simple list to 1318 make it easy for applications to parse. Furthermore, the single list format supports the override semantics 1319 where a property on a VirtualSystem may override one defined on a parent 1320 VirtualSystemCollection. The overridden property shall not be in the list. 1321 The value of the ovfenv:id attribute of the Environment element shall match the value of the ovf:id 1322 attribute of the VirtualSystem entity describing this virtual machine. The PropertySection contains 1323 the key/value pairs defined for all the properties specified in the OVF descriptor for the current virtual 1324 machine, as well as properties specified for the immediate parent VirtualSystemCollection, if one 1325 exists. 1326 An Entity element shall exist for each sibling VirtualSystem and VirtualSystemCollection, if 1327 any are present. The value of the ovfenv:id attribute of the Entity element shall match the value of 1328 the ovf:id attribute of the sibling entity. The Entity elements contain the property key/value pairs in 1329 the sibling’s OVF environment documents, so the content of an Entity element for a particular sibling 1330 shall contain the exact PropertySection seen by that sibling. This information can be used, for 1331 example, to make configuration information such as IP addresses available to VirtualSystems being 1332 part of a multi-tiered application. 1333 Table 8 shows the core sections that are defined. 1334 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 1335 The environment document is extensible by providing new section types. A consumer of the document 1336 should ignore unknown section types and elements. 1337 11.2 Transport 1338 The environment document information can be communicated in a number of ways to the guest software. 1339 These ways are called transport types. The transport types are specified in the OVF descriptor by the 1340 ovf:transport attribute of VirtualHardwareSection. Several transport types may be specified, 1341 separated by a single space character, in which case an implementation is free to use any of them. The Version 1.0.0 DMTF Standard 37
  • 38. Open Virtualization Format Specification DSP0243 1342 transport types define methods by which the environment document is communicated from the 1343 deployment platform to the guest software. 1344 To enable interoperability, this specification defines an "iso" transport type which all implementations 1345 that support CD-ROM devices are required to support. The iso transport communicates the environment 1346 document by making a dynamically generated ISO image available to the guest software. To support the 1347 iso transport type, prior to booting a virtual machine, an implementation shall make an ISO 9660 read- 1348 only disk image available as backing for a disconnected CD-ROM. If the iso transport is selected for a 1349 VirtualHardwareSection, at least one disconnected CD-ROM device shall be present in this section. 1350 Support for the "iso" transport type is not a requirement for virtual hardware architectures or guest 1351 operating systems which do not have CD-ROM device support. 1352 The ISO image shall contain the OVF environment for this particular virtual machine, and the environment 1353 shall be present in an XML file named ovf-env.xml that is contained in the root directory of the ISO 1354 image. The guest software can now access the information using standard guest operating system tools. 1355 If the virtual machine prior to booting had more than one disconnected CD-ROM, the guest software may 1356 have to scan connected CD-ROM devices in order to locate the ISO image containing the ovf-env.xml 1357 file. 1358 To be compliant with this specification, any transport format other than iso shall be given by a URI which 1359 identifies an unencumbered specification on how to use the transport. The specification need not be 1360 machine readable, but it shall be static and unique so that it may be used as a key by software reading an 1361 OVF descriptor to uniquely determine the format. The specification shall be sufficient for a skilled person 1362 to properly interpret the transport mechanism for implementing the protocols. It is recommended that 1363 these URIs are resolvable. 38 DMTF Standard Version 1.0.0
  • 39. DSP0243 Open Virtualization Format Specification 1364 ANNEX A 1365 (informative) 1366 1367 Symbols and Conventions 1368 XML examples use the XML namespace prefixes defined in Table 1. The XML examples use a style to 1369 not specify namespace prefixes on child elements. Note that XML rules define that child elements 1370 specified without namespace prefix are from the namespace of the parent element, and not from the 1371 default namespace of the XML document. Throughout the document, whitespace within XML element 1372 values is used for readability. In practice, a service can accept and strip leading and trailing whitespace 1373 within element values as if whitespace had not been used. 1374 Syntax definitions in Augmented BNF (ABNF) use ABNF as defined in IETF RFC2234 with the following 1375 exceptions: 1376 • Rules separated by a bar (|) represent choices, instead of using a forward slash (/) as defined in 1377 ABNF. 1378 • Any characters must be processed case sensitively, instead of case-insensitively as defined in 1379 ABNF. 1380 • Whitespace (i.e., the space character U+0020 and the tab character U+0009) is allowed between 1381 syntactical elements, instead of assembling elements without white space as defined in ABNF. 1382 Version 1.0.0 DMTF Standard 39
  • 40. Open Virtualization Format Specification DSP0243 1383 ANNEX B 1384 (informative) 1385 1386 Change Log Version Date Description 1.0.0a 2008-06-04 Work in progress release 1.0.0b 2008-07-23 Preliminary release Revised XML schemas to use substitution groups 1.0.0c 2008-08-13 Preliminary release Errata 1.0.0d 2008-08-18 Preliminary release 1.0.0e 2009-01-15 Preliminary release Updated extensibility model Errata 1387 40 DMTF Standard Version 1.0.0
  • 41. DSP0243 Open Virtualization Format Specification 1388 ANNEX C 1389 (normative) 1390 1391 OVF XSD 1392 Normative copies of the XML schemas for this specification may be retrieved by resolving the URLs 1393 below. 1394 1395 http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.0.0.xsd 1396 http://schemas.dmtf.org/ovf/environment/1/dsp8027_1.0.0.xsd 1397 Any xs:documentation content in XML schemas for this specification is informative and provided only 1398 for convenience. 1399 Normative copies of the XML schemas for the WS-CIM mapping (DSP0230) of 1400 CIM_ResourceAllocationSystemSettingsData and CIM_VirtualSystemSettingData may be 1401 retrieved by resolving the URLs below. 1402 1403 http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2+/CIM_VirtualSystemSettingData.xsd 1404 http://schemas.dmtf.org/wbem/wscim/1/cim- 1405 schema/2+/CIM_ResourceAllocationSettingData.xsd 1406 This specification is based on the following CIM MOFs: 1407 CIM_VirtualSystemSettingData.mof 1408 CIM_ResourceAllocationSettingData.mof 1409 CIM_OperatingSystem.mof Version 1.0.0 DMTF Standard 41