Virtual Infrastructure Ovf Manager APIs
Service interface to parse and generate OVF descriptors.
The purpose of this interface is to make it easier for callers to import VMs and vApps from OVF packages and to export VI packages to OVF. In the following description, the term "client" is used to mean any caller of the interface.
This interface only converts between OVF and VI types. To actually import and export entities, use ResourcePool.importVApp, VirtualMachine.exportVm and VirtualApp.exportVApp.
Import
For the import scenario, the typical sequence of events is as follows:
The client calls parseDescriptor to obtain information about the OVF descriptor. This typically includes information (such as a list of networks) that must be mapped to VI infrastructure entities.
The OVF descriptor is validated against the OVF Specification, and any errors or warnings are returned as part of the ParseResult. For example, the parser might encounter a section marked required that it does not understand, or the XML descriptor might be malformed.
The client decides on network mappings, datastore, properties etc. It then calls createImportSpec to obtain the parameters needed to call ResourcePool.importVApp.
If any warnings are present, the client will review these and decide whether to proceed or not. If errors are present, the ImportSpec will be missing, so the client is forced to give up or fix the problems and then try again.
The client now calls ResourcePool.importVApp, passing the ImportSpec as a parameter. This will create the virtual machines and VirtualApp objects in VI and return locations to which the files of the entity can be uploaded. It also returns a lease that controls the duration of the lock taken on the newly created inventory objects. When all files have been uploaded, the client must release this lease.
Export
Creating the OVF descriptor is the last part of exporting an entity to OVF. At this point, the client has already downloaded all files for the entity, optionally compressing and/or chunking them (however, the client may do a "dry run" of creating the descriptor before downloading the files. See OvfManager.createDescriptor).
In addition to the entity reference itself, information about the choices made on these files is passed to createDescriptor as a list of OvfFile instances.
The client must inspect and act upon warnings and errors as previously described.
No matter if the export succeeds or fails, the client is responsible for releasing the shared state lock taken on the entity (by VirtualMaching.exportVm or VirtualApp.exportVApp) during the export.
Error handling
All result types contain warning and error lists. Warnings do not cause processing to fail, but the caller (typically, the user of a GUI client) may choose to reject the result based on the warnings issued.
Errors cause processing to abort by definition.