Vendors can save themselves a lot of time and effort by creating VMware OVF appliances. These appliances are preconfigured...
packages of operating systems and applications that the vendor creates, then gives to customers. The following tutorial explains how to create and customize the OVF appliance.
A virtual appliance (VA) is a virtual machine (VM) image file that contains a preconfigured operating system (OS) and a single application. VAs are intended to simplify delivery and operation of an application, so they are relatively bare-bones packages.
There are closed VAs and open VAs. A closed VA is always packaged, distributed, maintained, updated and managed as a unit, while an open VA is can be modified by customers, typically through a Web interface.
What the appliance contains
An application deployment begins with a manifest, which consists of three or more files. The first file is the core VMDK file, the actual pre-made appliance disks. The second file is the MF file, which is the manifest file containing a list of all files required to deploy the appliance. The third file is the OVF file, which is the configuration script file in XML that contains the metadata for the appliance and details such things as references to external files.
VMDK files can have more than one disk, depending on requirements and how the appliance creator deems it needs to be set up.
It's important to note that MF files will also contain an SHA1 computed checksum for all the files to detect any corruption or changes prior to deployment. A system will still install the appliance if you remove this file entirely, but this is not advised, since the checksum provides security and integrity checking.
Creating the appliance
To create the appliance, start by creating a new VM with a minimal CentOS system or another Linux distribution if desired. I'd recommend removing unused virtual hardware, such as floppy drives. They will not be used, and it saves a small amount of RAM.
Next, connect your CentOS Installation media. Boot your VM and go through the installation. Once it is fully installed, log in as root via the console and configure the automatic booting of the machine by using vi to edit /etc/sysconfig/network-scripts/ifcfg-eth0 and change the line ONBOOT=NO to ONBOOT=YES. Bring up the interface by typing ifup eth0.
Once this is complete and you have a DHCP address, assuming you have DHCP on your network, issue the command yum -y update to update your server to the latest version.
As we installed a minimal configuration, we will need to install Perl to install VMware Tools. Do this by issuing the command yum -y install perl. Once this is installed, you can install VMware Tools to provide enhanced performance by mounting the virtual CD-ROM and running through the install.
Now, reboot the server using the command reboot. After the reboot, the server should have an IP address and VMware Tools installed. The base installation is now complete. Make sure you disconnect any external media and power down the machine so it can be exported.
Deploying the appliance
Assuming no more work is required, the VM can now be deployed into an OVF or OVA file. In the second part of this tutorial, we will create more complex appliances. If you use an OVA file, it contains the entire VM, OVF file and everything required to distribute it and deploy the VM. It is, in essence, a fancy TAR file.
To export the appliance from the VMware infrastructure, open the VMware vSphere client and select the VM. Go to File >Export > Export to OVF template. From here, you can choose to export in either OVA or OVF format and select the destination for the export.
At this point, you can take the OVA and deploy it, but the file will lack some finish. By editing the XML file, we can add a disclaimer, owner and version information to the installer.
Modifying the OVF file
Export a copy of the system using the OVF option. Open the OVF in an editor and you'll see lots of XML data in there. This can be modified, but be warned: If you change any data in the file and then try and deploy a VM from it, it will refuse, stating that the SHA1 checksum is wrong. You can fix this by deleting the MF file, but a much better way to do it to update the checksums using OpenSSL.
To recalculate them, use the following command in the working directory:
openssl sha1 * > manifest.mf
manifest.mf for the VM name.
After fixing the manifest, there are many options you can configure. One basic example is to add a EULA or disclaimer that must be accepted before the system can be installed. Note that the entries in the manifest are all case-sensitive.
To add an EULA, edit the file by adding this to the </VirtualSystem> block:
This is our test EULA. You must accept before the system can be installed.
The XML tags are self-explanatory. You can add other XML components that will be seen on the installer, including the application version, product details and descriptions.
You can find lists of the allowable XML markup in the definition document located here.
In the next part, we'll look at securely signing our application, working with deploying multiple machines and the customized configuration required to install them.