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.

The upload workflow for OVF packages uses a combination of vCloud API requests and standard HTTP file transfer requests.

1

The client uses a POST request that specifies a name and description for the template, and a transfer format for the data.

2

The server returns an unresolved VAppTemplate element with (status="0") that includes an upload URL for the OVF descriptor.

3

The client uses an HTTP PUT request to upload the descriptor to the upload URL.

4

The server reads 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.

5

The client uses HTTP PUT requests to upload each of the files.

6

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.

The vCloud 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.

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, NewVirtualMachine1 and NewVirtualMachine2 become NewVirtualMac001 and NewVirtualMac002.

1

To initiate the OVF upload, a client makes a POST request to the uploadVAppTemplate URL of the target vDC. The request body is an UploadVAppTemplateParams element.

2

You upload the OVF descriptor by making a PUT request to an upload URL and supplying the descriptor’s contents as an Envelope element in the request body. If the request is valid, the server responds with a 200 OK status.

3

After an OVF descriptor is uploaded, the server validates it and, if it is valid, updates the corresponding template with upload URLs for each of the files referenced in the descriptor. You must retrieve the template to see these URLs.

4

You can use a PUT request to upload each file that the vApp template references.