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 VMware Cloud Director 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 VMware Cloud Director 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.
Starting with vCloud Director 9.5, vApps and virtual machines support IPv6 connectivity. You can assign IPv6 addresses to virtual machines connected to IPv6 networks.
About OVF
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 VMware Cloud Director API itself.
Administrators and advanced users should become familiar with the details of the OVF standard before developing applications with the VMware Cloud Director 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 VMware Cloud Director API supports upload and download of OVF files. It also supports download, but not upload, of OVA files.
About DMTF, CIM, and RASD
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 VMware Cloud Director 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
vApp Life Cycle
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.
For a full list of the VMware Cloud Director API user operations, see the Cloud API Schema Reference at https://code.vmware.com.
