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.


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.


If you have an OVF package that you want to deploy immediately as a vApp, without creating a vApp template and corresponding catalog item, make an instantiateOvf request. See Create a vApp From an OVF Package.

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.

Upload or download of packages that include OVF ExtraConfig elements typically require the user to have additional rights specific to the ExtraConfig key attribute. SeeUsing Metadata to Control Virtual Machine Placement.

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.


To initiate the OVF upload, a client makes a POST request to an action/upload link in the target catalog. The type of this link is application/vnd.vmware.vcloud.uploadVAppTemplateParams+xml. The request body is an UploadVAppTemplateParams element.


After the vApp template and corresponding catalog item have been created, you must retrieve the template to get the upload URL for the OVF descriptor.


You upload the OVF descriptor by making a PUT request to the upload URL created for it in the VAppTemplate. The request body is the descriptor's Envelope element. If the request is valid, the server responds with a 200 OK status.


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.


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