VMware vCloud Director Cookbook
上QQ阅读APP看书,第一时间看更新

Introduction

One thing that needs to be said about vApps is that they actually come in two completely different versions: the vSphere vApp and the vCloud vApp.

vSphere and vCloud vApps

The vSphere vApp concept was introduced in vSphere 4.0 as a container for VMs. In vSphere, a vApp is essentially a resource pool with some extras, such as the starting and stopping order and (if you configured it) network IP allocation methods. The idea is for the vApp to be an entity of VMs that build one unit. Such vApps can then be exported or imported using OVF (Open Virtualization Format). A very good example of a vApp is VMware Operations Manager. It comes as a vApp in an OVF and contains not only the VMs but also the startup sequence as well as setup scripts. When the vApp is deployed for the first time, additional information such as network settings are asked and then implemented. A vSphere vApp is a resource pool; it can be configured so that it will only demand resources that it is using; on the other hand, resource pool configuration is something that most people struggle with. A vSphere vApp is only a resource pool; it is not automatically represented as a folder within the VMs and Template view of vSphere, but is viewed there as a vApp, as shown in the following screenshot:

The vCloud vApp is a very different concept. First of all, it is not a resource pool. The VMs of the vCloud vApp live in the OvDC resource pool. However, the vCloud vApp is automatically a folder in the VMs and Template view of vSphere. It is a construct that is created by vCloud, and consists of VMs, a start and stop sequence, and networks. The network part is one of the major differences (next to the resource pool). In vSphere, only basic network information (IP's assignment, gateway, and DNS) is stored in the vApp. A vCloud vApp actually encapsulates the networks. The vCloud vApp networks are full networks, meaning they contain the full information for a given network including network settings and IP pools (for more details see Chapter 2, vCloud Networks, where we use this feature in various recipes). This information is kept while importing and exporting vCloud vApps, as shown in the following screenshot:

While I'm referring to vApps in this book, I will always mean vCloud vApps. If vCenter vApps feature anywhere in this book, they will be written as vCenter vApp.

Roles and rights

We will have a closer look at the influence of roles and what you can do with them in vCloud in Chapter 6, Working with vCloud Roles. However, I will mention in each recipe what default role you have to be a part of to execute the recipe.