A vCloud API client that has access to an OVF package can use a standard workflow to upload the package and create a vApp template.
The initial configuration of a vApp is established in the OVF package on which its source template is based. In the vCloud API, vApp templates are based OVF 1.0, an open standard format. For more information about OVF and how the vCloud API uses it, see About OVF.
An OVF package includes several kinds of files.
- An OVF descriptor
- An XML file that contains metadata that describe a virtual machine or collection of related virtual machines and the deployment environment they require. By convention, this file has the suffix .ovf.
- Virtual disk files
- The descriptor lists these files and includes information about their format.
- An optional certificate
- You can use this file to certify the authenticity of the package.
- An optional manifest
- Contains a SHA-1 digest of each of the files in the package.
Upload Workflow
The upload workflow for OVF packages uses a combination of vCloud API requests and standard HTTP file transfer requests.
- The client makes a POST request to the catalog chosen to hold the template derived form the uploaded OVF. The request body specifies a name, description, and other parameters used when creating the template.
- The server returns a CatalogItem that references a vApp template.
- The client makes a GET request to the entity reference in the CatalogItem to retrieve the VAppTemplate, which includes an upload URL for the OVF descriptor. Because the template is not yet complete, the VAppTemplate element has
status="0". - The client makes a PUT request to the upload URL and supplies the OVF descriptor in the request body.
- The server processes the descriptor and modifies the vAppTemplate to include an upload URL for each file listed in the References section of the descriptor. While the server is modifying the vAppTemplate, the client makes periodic requests for it and examines the response for additional upload URLs. When the response contains additional upload URLs that were not present in the initial response, template construction is complete.
- The client uses PUT requests to upload each of the files.
- If the OVF package includes a manifest file, the entire upload is validated against the contents of the manifest file.
Both monolithic and ranged, or chunked, PUT requests are supported. After starting an upload, a client can make periodic requests to assess its progress. After all of the files are uploaded (and validated if a manifest is present), the server processes them and updates the vApp template. When processing is complete, the server sets the value of the template's status attribute to 8, indicating that it is ready for use. This status value indicates that all of the virtual machines in the template are powered off. For more information, including a complete list of possible status values and their meanings, see Object Creation Status.
Restrictions on Uploaded Content
The VMware Cloud Director transfer service imposes the following restrictions on uploaded OVF content:
- You can upload either OVF 1.0 or OVF 1.1 content. OVF 1.1 packages are converted to OVF 1.0 for download, and any OVF 1.1 content is lost.
- Upload or download of packages that include OVF ExtraConfig elements typically require the user to have additional rights specific to the ExtraConfig key attribute. SeeSpecifying Advanced Virtual Machine Settings with ExtraConfig Elements.
- You cannot upload a compressed OVF package.
- If you upload an OVF package in which any VirtualSystem element has an ovf:id attribute value that is longer than 13 characters, the name of the Vm that represents that VirtualSystem in the vAppTemplate that the upload creates is rewritten as the first 13 characters of the ovf:id attribute followed by three digits. For example,
NewVirtualMachine1andNewVirtualMachine2becomeNewVirtualMac001andNewVirtualMac002.
