Creating a simple Open Virtual Appliance (OVA) deployment is easy enough to do, as shown in the first part of this...
series. The real power of OVA and OVF files is that you can deploy more than just a single basic VM; you can also create more complicated and useful vApps or a collection of VMs that make up an appliance group.
The easiest way to package multiple VMs into a vApp is to create the vApp in your setup. Start by highlighting the cluster that holds all the preconfigured VMs you built. From the vSphere client File menu, select New vApp. Alternatively, if you are a fan of the Hosts and Clusters view, you can merely right-click and select New vApp. Give the vApp the name you want to appear in your deployment.
On the next page, you have to choose the resources. Unless you have a compelling reason, leave CPU and memory resources alone and click Finish. Drag and drop the VMs into your VMware vApp. Note that modifying the resource pools is beyond the scope of this introductory article.
Next, edit the VMware vApp settings -- right-click on the vApp and choose Edit Settings. Select the Start Order tab for the startup action. We can choose either a time-based delay between starting up the VMs or clicking the button that says "… or VMware Tools are ready." The latter is an excellent way to make sure your database server starts and is functioning before the Web server starts.
You can also use the arrows to determine the application startup order -- or even groups of servers in parallel, if appropriate. Once this is done, export by going to File to create the vApp.
Before you export, make sure you have detached any installed ISO files to prevent issues with missing disks. You can also do this by checking the "Include Image files attached to floppy and CD/DVD in the OVF package" option
After creating the appliance, you can modify its OVF package to include an End User License Agreement. There are dozens of configuration modifications you can perform on the OVF file to customize the installation scenario. We can do a couple of intermediate steps to further enhance the security of the OVA and also tweak the appliances to allow some post-installation configuration. You will need to modify the OVF file directly to incorporate these. It's important to note the OVF file will be stored in the directory to which you selected to export your vApp.
To secure an OVA, you can sign it with a digital key or certificate. You may have seen this on other OVF deployments. Unfortunately, many manifests aren't signed. I use a tool called ovftool. Before signing the manifest, you need a key, preferably signed by a certification authority. Using a self-signed certification will display a warning when you verify the certificate. To verify, use the following command:
ovftool --privateKey=myprivatekey.pem MyVapp.ovf SignedVapp.ovf.
To confirm that the key has been signed, run through the installation. You will see that it has been signed; there is a red alert because our example used our own signing key rather than one from a certificate authority.
The other way to confirm is to use the ovftool to interrogate the manifest, using the command:
When you enter this command, the manifest will be different from a standard OVF and will have certificate data embedded in it. You can find more information on signing OVFs and the use of certificates on VMware's website.
OVFtool has other uses as well. It can also be used to interrogate other OVFs and OVAs. There are many more options available, which can be added to the OVF deployment file, but you need to add them manually. Some functions will allow you to extend the usefulness of your deployment.
You can also create multiple configurations, like multiple memory configurations, if need be.
All OVF deployment files break down into several sections in XML. Here's a quick overview of a legal OVF file and the order in which sections appear:
<References>: This section gives all the information about the VMDK and other files used, along with the size.
<DiskSection>: Implements the disk to VMs.
<NetworkSection>: Associates a VM with a port group.
<ResourceAllocationSection>: Specifies resources and resource limits.
<ProductSection>: Gives details of the application, application owners and other similar information.
<VirtualSystemCollection>: Lists multiple VM systems as noted below.
<VirtualSystem>: Denotes the start of a VM that will be built. Within this envelope you can define such items as the hardware types and resources available to the machine.
Using vApps saves time, reduces headaches
Using vApps is an excellent way to deploy applications, especially applications that have critical interdependencies. Even big, high-value applications such as EMC UniSphere are deployed this way. It also cuts down on support calls and issues because it limits the interactions and potential for errors. This, in turn, saves time for users.