A vApp object contains one or more virtual machines, and provides detailed specifications of those virtual machines and the networks to which they connect. The vCloud API supports programmatic access to a range of self-service datacenter operations that allow users to create, configure, deploy, and operate vApps.

The initial configuration of a vApp and the virtual machines it contains is established in the OVF package on which its source template is based. In the vCloud API, vApp templates are based on OVF 1.0. These templates can be retrieved from catalogs and transformed into virtual systems, called vApps, through a process called instantiation, which binds a template’s abstract resource requirements to resources available in a VDC.

After a vApp has been created, using any of the methods described in About Instantiation, you can make further changes to its configuration using procedures like the ones shown in Reconfiguring vApps and Virtual Machines. All configuration changes you make during instantiation or reconfiguration are discarded when the vApp is deleted, but you can preserve them by capturing the vApp as a template. See Capture a vApp as a Template.

OVF is a widely accepted standard format that applies to many virtualization technologies.

Virtual machines and appliances are distributed as OVF packages by many vendors.

Many vendors, including VMware, offer tools that simplify creating and customizing OVF, support converting virtual machines on existing virtualization platforms to OVF, or both.

OVF can express the complex relationships between virtual appliances in enterprise applications. The author of the appliance can handle most of the complexity, rather than the user who deploys it.

OVF is extensible, allowing new policies and requirements to be inserted by ISVs and implemented by the virtualization platforms that support them without requiring changes to other clients, other platforms, or the vCloud API itself.

Administrators and advanced users should become familiar with the details of the OVF standard before developing applications with the vCloud API. The complete OVF specification document is available at http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf. An informative white paper on OVF is available at http://www.dmtf.org/standards/published_documents/DSP2017_1.0.0.pdf.

A virtual machine is typically made up of one or more virtual disk files that contain the operating system and applications that run on the virtual machine, and a configuration file containing metadata that describe how the virtual machine is configured and deployed. An OVF package includes these components, as well as optional certificate and manifest files. The package can be distributed and stored as a collection of individual files, or as a single archive (OVA) file. The vCloud API does not support uploading or downloading OVA files.

Virtual hardware in OVF packages elements is defined using an open standard framework established by the Distributed Management Task Force (DMTF). This framework, called the Common Information Model (CIM), defines virtual hardware resources using the ResourceAllocationSettingData (RASD) schema. In this schema, each class of virtual hardware is represented as an Item element with a specific ResourceType. Many vCloud API operations that deploy and configure vApps and virtual machines require you to understand and sometimes modify RASD Item elements.

You can download the RASD schema files and related information from http://www.dmtf.org/standards/cim/cim_schema_v2191

A vApp contains one or more Vm elements, which represent individual virtual machines. It also contains information that defines operational details for the vApp and the virtual machines that it contains. The vApp lifecycle includes several distinct states:

An OVF package, the form in which vApps are typically distributed.

A vApp template, created when a client uploads an OVF package to a catalog.

An undeployed vApp, created when a vApp template is instantiated without also being deployed, or a deployed vApp is undeployed.

A deployed vApp, ready to be powered on and operated. Instantiation can include deployment, power-on, or both.

vApp State Transitions
State diagram illustrating how an uploaded OVF package becomes a vApp template, and an instantiated template becomes a vApp