Virtual Applications

What is a vApp?

vApp is short for Virtual Application. According to the vSphere Basic System Administration Guide, “A vApp is a container, like a resource pool, that can contain one or more virtual machines. In addition, a vApp also shares some functionality with virtual machines. A vApp can power on and power off, and can also be cloned.” That definition can be confusing and does not really explain the full power of a vApp over a resource pool or a folder.

How do I pronounce vApp?

As fun as it is to simply call them “vapps”, the common pronunciation is “vee-app.”

Are vApps exclusive to VMware?

Despite the heavy use of vApps in VMware vSphere, VMware vCloud Director and the vCloud Datacenter Service, vApps are actually defined and governed by the Distributed Management Task Force (DMTF) packaging standard called the Open Virtualization Format (OVF).

vApps sound a lot like folders?

They do, but a folder within Virtual Center, while useful for grouping Virtual Machines (VMs) together and making management easier, is pretty limited. Putting VMs together in a folder organizes them better but does not establish common characteristics like networking, security, or enable management controls like cloning, stopping, starting, start-up precedence or timing. A vApp adds all of these capabilities in the form of meta data that is stored and managed for the vApp itself and applies to all VMs within the vApp.

For example, if you wanted to create a specific network like 10.10.10.150.x for all of the VMs to use, add a DHCP service in the vApp to serve IP addresses from that IP range and configure the vShield firewall to only allow RDP (TCP 3389) you can set that all up and it will be applied and enforced for any existing VMs in the vApp and any that you might add later.

Is a vApp a Resource Group?

The simple answer is no. However, vApps can live inside of Resource Groups just like Virtual Machines do. They can also live inside of catalogs but we’ll get to that later. The cool thing is that a vApp can exist inside of a Resource Group.

How do vApps work within a Resource Group?

vApps that exist inside of a particular Resource Group are subject to all capacity, configuration, limitations and policies that govern that Resource Group. If the Resource group only has 10 Gigahertz, the vApp will be able to use and will also be limited to that capacity. If there is more than one vApp in the Resource Group, they will contest with each other for those resources. If the Resource Group is configured for High Availability failover, then if the hardware upon which the vApp is running fails, the whole vApp will failover. If the Resource Group is configured for hardware affinity (it has to run on a certain server or servers) then the vApp will be forced to stay on those servers.

When do I use a vApp versus a Folder or a Resource Group?

Condition vApp Folder Resource Group
Building applications that require more than one VM x
Building applications that require custom security x
Building applications that require custom networking x
Building applications that require custom startup parameters x
Building applications to be stored and provisioned from a catalog x
Building applications and VMs for the cloud x x
Organizing similar VMs and/or vApps to simplify management x
Organizing large numbers of VMs and/or vApps to simplify management x
Creating pools of hardware resources (CPU/RAM) x
Creating pools of hardware resources that require affinity x
Creating pools of hardware resources that require failover x

Why vApps rock:

Unique feature differences between vApps and resources pools or folders:

  • Rapid provisioning – Provisioning a vApp from your catalog is extremely simple. In a few mouse clicks, regardless of whether the vApp contains one or one hundred virtual machines, you can start the provisioning process and vSphere or vCloud Director will do the rest of the work.
  • Complex provisioning – Because all of the networking, startup and security information is contained inside of the vApp, when you provision a new vApp all of that is automatically set up for you. This allows for extremely consistent deployments of complex applications. You simply configure it once and then clone as many copies as you need.
  • Self-service for end users – Services like the VMware vCloud Datacenter Service from Bluelock and products like VMware’s vCloud Request Manager make extensive use of vApps to simplify the way that self-service works for end users. The systems administrator can create the initial vApp and then, through the web interface in vCloud Director or Request Manager, provision their own copy of the already tested and configured vApp into their own Virtual Datacenter. This works regardless of whether their Virtual Datacenter is hosted local or in a public vCloud like Bluelock.
Posted on:

Comments are closed.

Archives

Categories

Meta

Subscribe