ANSI INCITS469-2010 Information technology - Open Virtualization Format (OVF) Specification《信息技术.开放虚拟化格式(OVF)规范》.pdf

《ANSI INCITS469-2010 Information technology - Open Virtualization Format (OVF) Specification《信息技术.开放虚拟化格式(OVF)规范》.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS469-2010 Information technology - Open Virtualization Format (OVF) Specification《信息技术.开放虚拟化格式(OVF)规范》.pdf（47页珍藏版）》请在麦多课文档分享上搜索。

1、American National StandardDeveloped byfor Information Technology Open Virtualization Format(OVF) SpecificationINCITS 469-2010INCITS 469-2010Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Provided by IHSNot for ResaleNo reproduction or networking per

2、mitted without license from IHS-,-,-INCITS 469-2010American National Standardfor Information Technology Open Virtualization Format(OVF) SpecificationSecretariatInformation Technology Industry CouncilApproved July 20, 2010 American National Standards Institute, Inc.Provided by IHSNot for ResaleNo rep

3、roduction or networking permitted without license from IHS-,-,-Approval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgement of

4、 th e ANSI Boar d ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that allviews and objections be considered, and that a concerted e

5、ffort be madetowards their resolution.The use of Amer ican Nation al Stan dards is comp letely vo luntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchasing, or usingproducts, processes, or procedures not co

6、nforming to the standards.The American National Standards Institute does not develop standards andwill in no circ umstances give an inte rpretation of any A merican NationalStandard. Moreover, no person shall have the right or authority to issue aninterpretation of an American National Standard in t

7、he name of the AmericanNational Sta ndards Institute. Re quests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the Amer

8、ican National StandardsInstitute require tha t action b e taken pe riodically to r eaffirm, r evise, orwithdraw this stan dard. Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standards Institute.American National S

9、tandardPublished byAmerican National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2010 by Information Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without pri

10、or written permission of ITI, 1101 K Street NW, Suite 610Washington, DC 20005. Printed in the United States of AmericaCAUTION: The developers of this standard have requested that holders of patents that may berequired for the implementation of the standard disclose such patents to the publisher. How

11、ever,neither the developers nor the publisher have undertaken a patent search in order to identifywhich, if any, patents may apply to this standard. As of the date of publication of this standardand following calls for the identification of patents that may be required for the implementation ofthe s

12、tandard, no such claims have been made. No further patent search is conducted by the de-veloper or publisher in respect to any standard it processes. No representation is made or impliedthat licenses are not required to avoid infringement in the use of this standard.Provided by IHSNot for ResaleNo r

13、eproduction or networking permitted without license from IHS-,-,-CONTENTS Foreword.iii 1 Scope1 2 Normative References.1 3 Terms and Definitions.2 4 Symbols and Abbreviated Terms4 5 OVF Packages4 5.1 OVF Package Structure4 5.2 Virtual Disk Formats6 5.3 Distribution as a Single File6 5.4 Distribution

14、 as a Set of Files.7 6 OVF Descriptor7 7 Envelope Element.8 7.1 File References.9 7.2 Content Element.10 7.3 Extensibility.11 7.4 Conformance12 8 Virtual Hardware Description.13 8.1 VirtualHardwareSection13 8.2 Extensibility.14 8.3 Virtual Hardware Elements.14 8.4 Ranges on Elements.17 9 Core Metada

15、ta Sections19 9.1 DiskSection.19 9.2 NetworkSection.21 9.3 ResourceAllocationSection.21 9.4 AnnotationSection.22 9.5 ProductSection22 9.6 EulaSection.25 9.7 StartupSection26 9.8 DeploymentOptionSection27 9.9 OperatingSystemSection29 9.10 InstallSection.29 10 Internationalization29 11 OVF Environment

16、31 11.1 Environment Document31 11.2 Transport.33 ANNEX A (informative) Symbols and Conventions.34 ANNEX B (informative) Change Log35 ANNEX C (normative) OVF XSD.36 Bibliography37 i Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 469-2010 ii Ta

17、bles Table 1 XML Namespace Prefixes8 Table 2 Actions for Child Elements with ovf:required Attribute.14 Table 3 HostResource Element.16 Table 4 Elements for Virtual Devices and Controllers.17 Table 5 Core Metadata Sections.19 Table 6 Property Types25 Table 7 Property Qualifiers25 Table 8 Core Section

18、s33 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Foreword(This foreword is not part of American National Standard INCITS 469-2010.)The Open Virtualization Format (OVF) Specification describes an open, secure, por-table, efficient and extensible fo

19、rmat for the packaging and distribution of software to be run in virtual machines. The key properties of the format are as follows: - Optimized for distribution: OVF supports content verification and integrity checking based on industry-standard public key infrastructure, and it provides a basic sch

20、eme for management of software licensing.- Optimized for a simple, automated user experience: OVF supports valida-tion of the entire package and each virtual machine or metadata component of the OVF during the installation phases of the virtual machine (VM) lifecycle management process. It also pack

21、ages with the package relevant user-read-able descriptive information that a virtualization platform can use to stream-line the installation experience. - Supports both single VM and multiple-VM configurations: OVF supports both standard single VM packages and packages containing complex, multi-tier

22、 services consisting of multiple interdependent VMs.- Portable VM packaging: OVF is virtualization platform neutral, while also en-abling platform-specific enhancements to be captured. It supports the full range of virtual hard disk formats used for hypervisors today, and it is exten-sible, which al

23、low it to accommodate formats that may arise in the future. Vir-tual machine properties are captured concisely and accurately.- Vendor and platform independent: OVF does not rely on the use of a specific host platform, virtualization platform, or guest operating system.- Extensible: OVF is immediate

24、ly useful - and extensible. It is designed to be ex-tended as the industry moves forward with virtual appliance technology. It also supports and permits the encoding of vendor-specific metadata to sup-port specific vertical markets.- Localizable: OVF supports user-visible descriptions in multiple lo

25、cales, and it supports localization of the interactive processes during installation of an ap-pliance. This capability allows a single packaged appliance to serve multiple market opportunities.- Open standard: OVF has arisen from the collaboration of key vendors in the industry, and it is developed

26、in an accepted industry forum as a future stan-dard for portable virtual machines.It is not an explicit goal for OVF to be an efficient execution format. A hypervisor is allowed but not required to run software in virtual machines directly out of the Open Virtualization Format.This standard contains

27、 four annexes. Annex C is normative and is considered part ofthis standard. Annexes A, B, and D are informative and are not considered part ofthis standard.Requests for interpretation, suggestions for improvement or addenda, or defect re-ports are welcome. They should be sent to InterNational Commit

28、tee for InformationTechnology Standards (INCITS), ITI, 1101 K Street, NW, Suite 610, Washington, DC20005.iiiProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-This standard was processed and approved for submittal to ANSI by INCITS. Com-mittee approval

29、of this standard does not necessarily imply that all committee mem-bers voted for its approval. At the time it approved this standard, INCITS had thefollowing members:Don Wright, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems, IncScott FosheeSteve Zilles

30、(Alt.)AIM Global, Inc.Dan MullenCharles Biss (Alt.)Apple Computer, Inc.Kwok LauHelene Workman (Alt.)David Singer (Alt.)Distributed Managment Task ForceJohn CrandallJeff Hilland (Alt.)Electronic Industries AllianceEdward Mikoski, Jr.Henry Cuschieri (Alt.)EMC CorporationGary RobinsonFarance, IncFrank

31、FaranceTimothy Schoechle (Alt.)GoogleZaheda BhoratGS1 US.Ray DelnickiFrank Sharkey (Alt.)James Chronowski (Alt.)Mary Wilson (Alt.)Hewlett-Packard Company.Karen HigginbottomPaul Jeran (Alt.)IBM CorporationGerald LaneRobert Weir (Alt.)IEEEBill AshTerry DeCourcelle (Alt.)Jodie Haasz (Alt.)Bob Labelle (

32、Alt.)Intel.Philip WennblomGrace Wei (Alt.)Stephen Balogh (Alt.)Lexmark International.Don WrightDwight Lewis (Alt.)Paul Menard (Alt.)Microsoft CorporationJim HughesDave Welsh (Alt.)Mark Ryland (Alt.)John Calhoun (Alt.)National Institute of Standards 160-bit digest in 40-digit hexadecimal hex-digit =

33、“0“ | “1“ | “2“ | “3“ | “4“ | “5“ | “6“ | “7“ | “8“ | “9“ | “a“ | “b“ | “c“ | “d“ | “e“ | “f“ sp = %x20 nl = %x0A EXAMPLE 2: The following example show the partial contents of a manifest file: SHA1(package.ovf)= 237de026fb285b85528901da058475e56034da95 SHA1(vmdisk1.vmdk)= 393a66df214e192ffbfedb78528

34、b5be75cc9e1c3 An OVF package may be signed by signing the manifest file. The digest of the manifest file is stored in a certificate file with extension .cert file along with the base64-encoded X.509 certificate. The .cert file shall have the same base name as the .ovf file and be a sibling of the .o

35、vf file. A consumer of the OVF package shall verify the signature and should validate the certificate. The format of the certificate file shall be as follows: certificate_file = manifest_digest certificate_part manifest_digest = algorithm “(“ file_name “)“ “=“ sp signed_digest nl algorithm = “SHA1“

36、signed_digest = *( hex-digit) certificate_part = certificate_header certificate_body certificate_footer certificate_header = “-BEGIN CERTIFICATE-“ nl certificate_footer = “-END CERTIFICATE-“ nl certificate_body = base64-encoded-certificate nl ; base64-encoded-certificate is a base64-encoded X.509 ;

37、certificate, which may be split across multiple lines hex-digit = “0“ | “1“ | “2“ | “3“ | “4“ | “5“ | “6“ | “7“ | “8“ | “9“ | “a“ | “b“ | “c“ | “d“ | “e“ | “f“ sp = %x20 nl = %x0A EXAMPLE 3: The following list of files is an example of a signed OVF package: package.ovf package.mf package.cert de-DE-

38、resources.xml vmdisk1.vmdk vmdisk2.vmdk resource.iso EXAMPLE 4: The following example shows the contents of a sample OVF certification file, where the SHA1 digest of the manifest file has been signed with a 512 bit key: SHA1(package.mf)= 7f4b8efb8fe20c06df1db68281a63f1b088e19dbf00e5af9db5e8e3e319de

39、7019db88a3bc699bab6ccd9e09171e21e88ee20b5255cec3fc28350613b2c529089 5 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 469-2010 -BEGIN CERTIFICATE- MIIBgjCCASwCAQQwDQYJKoZIhvcNAQEEBQAwODELMAkGA1UEBhMCQVUxDDAKBgNV BAgTA1FMRDEbMBkGA1UEAxMSU1NMZWF

40、5L3JzYSB0ZXN0IENBMB4XDTk1MTAwOTIz MzIwNVoXDTk4MDcwNTIzMzIwNVowYDELMAkGA1UEBhMCQVUxDDAKBgNVBAgTA1FM RDEZMBcGA1UEChMQTWluY29tIFB0eS4gTHRkLjELMAkGA1UECxMCQ1MxGzAZBgNV BAMTElNTTGVheSBkZW1vIHNlcnZlcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC3 LCXcScWua0PFLkHBLm2VejqpA1F4RQ8q0VjRiPafjx/Z/aWH3ipdMVvuJGa/wFXb /nDFLD

41、lfWp+oCPwhBtVPAgMBAAEwDQYJKoZIhvcNAQEEBQADQQArNFsihWIjBzb0 DcsU0BvL2bvSwJrPEqFlkDq3F4M6EgutL9axEcANWgbbEdAvNJD1dmEmoWny27Pn Ims6ZOZB -END CERTIFICATE- The manifest and certificate files, when present, shall not be included in the References section of the OVF descriptor (see 7.1). This ensures that

42、the OVF descriptor content does not depend on whether the OVF package has a manifest or is signed, and the decision to add a manifest or certificate to a package can be deferred to a later stage. The file extensions .mf and .cert may be used for other files in an OVF package, as long as they do not

43、occupy the sibling URLs or path names where they would be interpreted as the package manifest or certificate. 5.2 Virtual Disk Formats OVF does not require any specific disk format to be used, but to comply with this specification the disk format shall be given by a URI which identifies an unencumbe

44、red specification on how to interpret the disk format. The specification need not be machine readable, but it shall be static and unique so that the URI may be used as a key by software reading an OVF package to uniquely determine the format of the disk. The specification shall provide sufficient in

45、formation so that a skilled person can properly interpret the disk format for both reading and writing of disk data. It is recommended that these URIs are resolvable. 5.3 Distribution as a Single File An OVF package may be stored as a single file using the TAR format. The extension of that file shal

46、l be .ova (open virtual appliance or application). EXAMPLE: The following example shows a sample filename for an OVF package of this type: D:virtualappliancesmyapp.ova For OVF packages stored as single file, all file references in the OVF descriptor shall be relative-path references and shall point

47、to files included in the TAR archive. Relative directories inside the archive are allowed, but relative-path references shall not contain “” dot-segments. Ordinarily, a TAR extraction tool would have to scan the whole archive, even if the file requested is found at the beginning, because replacement

48、 files can be appended without modifying the rest of the archive. For OVF TAR files, duplication is not allowed within the archive. In addition, the files shall be in the following order inside the archive: 1) OVF descriptor 2) OVF manifest (optional) 3) OVF certificate (optional) 4) The remaining files shall be in the same order as listed in the References section (see 7.1). Note that any external string resource bundle files for internationalization shall be first in the References section (see clause 10). 6 Provided by IHSNot for ResaleNo reproduction or netwo