How to Set up VMware vApp in vCenter Server in 4 steps

VMware vApps are perhaps one of the most underutilized features of vCenter Server. A vApp is an application container, like a resource pool if you will but not quite, containing one or more virtual machines. Similarly to a vm, a vApp can be powered on or off, suspended and even cloned. The feature I like best is the ability to have virtual machines power up (or shut down) in a sequential fashion using one single mouse click or command. Suppose you have a virtualized Microsoft-centric environment comprising a file server, a DNS server, a couple of AD domain controllers and an Exchange Server. VMware refers to such environments as multi-tiered applications.

Normally you would switch on the DNS server first, followed by the domain controllers, the file server and finally the Exchange server. The reverse sequence holds true when it comes to powering down the entire environment perhaps due to scheduled maintenance. A vApp allows you to group all these components under one logical container. Better still, you can specify the vm start up order and the time taken in between powering up or shutting down the next vm.

Before jumping in to show you how to create and set up a vApp in vCenter Server, I just need to outline the prerequisites, these being a vCenter Server managing a DRS enabled cluster (Figure 1) or any standalone host running ESXi 4.0 or higher.

Figure 1 – DRS enabled cluster in vCenter Server

Step 1: How to Create a vApp

Creating a vApp is the proverbial piece of cake. You can use both the vSphere traditional and Web clients (Figures 2-3), or if you’re so inclined, PowerCLI. After signing in to your vCenter Server, do the following;

• Change the view to “Host and Clusters”, right-click on the cluster object and select “New vApp”.

Figure 2 – Creating a vApp using the vSphere Web client

Figure 3 – Creating a vApp using the traditional vSphere client

• Specify a name for the vApp, select a data centre and click Next.

• Allocate the required resources and click Next. As a side note, these are the same resource allocation settings you would set for resource pools so take care when applying them.

• Press Finish to finalize the creation of the vApp.

Step 2: Configuring a vApp

Once you’ve created your vApp container, you can proceed to move the vms to it. Going back to the virtualized Microsoft environment example, I’ll first move a set of virtual machines to the vApp. Next, I’ll configure the “Start Order” of the VMs inside it. The process is best illustrated by means of a video so here it goes.

https://youtu.be/A_300SK0QE4

As you’ve seen in the video and as shown in Figure 4, a group is by default created for every vm. Each group can hold multiple vms but be aware that multiple vms residing under the same group will switch on or off concurrently regardless of time intervals set. To overcome this limitation, you simply place each vm in its own dedicated group. Note that for demonstration purposes, I’ve set the time interval to 5s (Figure 4). The default setting is of 120 seconds but generally you’ll need to experiment until you strike the correct balance which depends on the type of environments and multi-tier applications deployed as well as the performance of the overall infrastructure. The “VMware Tools are ready” option basically tells the vApp to wait until VMware Tools are running on the current vm before moving on to power up the next one in the chain. This is a great option to go by assuming VMware Tools are installed and running correctly.

Figure 4 – vApp start order

Alternatively, you can nest vApps. That’s right. You can create one or more vApps each with its own configuration. This provides you with a more granular approach based on system type. For instance, you’d be able to shut down the vApp containing the Exchange servers without affecting anything else under the parent vApp. Figure 5 illustrates a nested model with children vApps created for Domain Controllers and Exchange servers both of which residing under a common parent vApp.

Figure 5 – Nested vApps

Step 3: More vApp settings

Under the vApp settings you’ll see 3 tabs: Options, Start Order (which we’ve already covered) and vServices. The latter provides no value at all since the only service extension available is the one for vCenter. Moreover, this can only be bound to virtual machines so I’m not entirely sure why it is presented as an option.

You’ll find 4 categories under the Options tab, these being Resources (we’ve covered this as well), Properties (not applicable in this context), IP Allocation Policy and Advanced.

The IP Allocation Policy allows you to specify how network information is applied to the vms residing under the vApp. Fixed and DHCP are self-explanatory. The first simply means that vms will have statically assigned network settings. The second implies that the network settings are applied using a DHCP server.

The Transient option is a little bit more involving since you’ll need to create an IP Pool at the datacenter level and tie it to the network(s) your vApp vms are configured for. In the example below, I created a /24 network with 20 IP addresses in the range 10.0.0.11-30. Once the IP pool is set, the vms in the vApp will acquire an IP address from this pool which is released only when the vApp is powered off.

Step 4: Exporting, importing and cloning vApps

OVF is the default distribution format for vApps and consequently a vApp can be exported to as such. Exporting vApps is a great feature to have as it allows you to backup an entire environment to a single file which you can re-import at any time to the original hosting vCenter Server or an alternative one. Cloning is supported as well, the only caveat being that the vApp must be powered off before it can be cloned. The next video illustrates how a vApp is imported and exported to and from vCenter Server.

vApp-import-export

Cloning a vApp is just a matter of right-clicking on it and selecting “Clone”. Alternatively, you may wish to use PowerCli as follows (change the items in red accordingly);

New-VApp -name ‘AD Environment 2’ -Location (get-cluster ‘Cluster’) -VApp (get-vapp ‘AD Environment’) -Datastore ‘iSCSI LUN A’

Some additional PowerCLI cmdlets you’ll surely find handy are;

• Get-Vapp
• New-Vapp
• Start-VApp
• Export-Vapp 

Conclusion

As we have seen, vApps can be a great addition to one’s arsenal of VMware tricks. You’ll find vApps to be extremely handy in disaster recovery scenarios where you would want to automate and quickly power up mutually dependent virtual machines using a single click or command. vApps also lend themselves extremely well to any backup strategy by providing the means to quickly back up and restore multi-tiered applications or environments using a single OVF package, assuming they are static workloads. This in turn can be backed up or archived as part of a disaster recovery plan. When disaster strikes – touching wood! – the backed up OVF is restored to a make-shift or replacement vSphere infrastructure to quickly bring online any essential services you might need. Compare this to having to restore and power up each and every constituent virtual machine one at a time. Now, couple this with the fact that it only takes a few mouse clicks to create and configure a vApp and I think you’ll agree that vApps are too much of a good feature to overlook.

So do yourself a favor and give them the attention they deserve!

Thank you for stopping by.

[the_ad id=”4738″][the_ad id=”4796″]