5.1

Table Of Contents
Upload Workflow
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,” on page 311.
Restrictions on Uploaded Content
The vCloud Director transfer service imposes the following restrictions on uploaded OVF content:
n
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.
n
You cannot upload a compressed OVF package.
n
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 Initiating the OVF Upload on page 59
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 Uploading the OVF Descriptor on page 61
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 Retrieving the Upload URLs on page 62
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.
vCloud API Programming Guide
58 VMware, Inc.