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.
The upload workflow for OVF packages uses a combination of vCloud API requests and standard HTTP file transfer requests.
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. SeeSpecifying Advanced Virtual Machine Settings with ExtraConfig Elements. |
■
| |
■
|
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 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. |
2 | 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. |
3 | 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. |
4 | 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. |
5 | You can use a PUT request to upload each file that the vApp template references. |