In the previous article, we reviewed the concepts and basic approach to building your own VMware Virtual Appliance (OVF/OVA). In Part 2, we are now going to take a look at a reference implementation for building a Linux VA using VMware PhotonOS. Although I am using PhotonOS as the guest, you can apply these same techniques to any other Linux distribution of your choice.

Step 1 - Create a new VM in vCenter Server and then install PhotonOS using the ISO format. Once you have completed the OS installation, you may want to apply any patches or packages that you want included as part of your VA. Once that is done, go ahead and shut down the VM.

Step 2 - Select the VM in the vSphere Inventory and then click on Configure->vApp and then check the Enable vApp Options. Once enabled, select OVF environment for the IP allocation scheme. In the OVF Details tab, select VMware Tools for the OVF environment transport. (Optionally) You can specify some additional metadata including appliance name and URLs to help others who maybe consuming your VA once it has been exported to an OVF/OVA.

Step 3 - Next, add the following 6 OVF properties which will be used as input to configure networking within PhotonOS. Click Add and provide a Label, Key and optional Category.



Label Key Category Hostname guestinfo.hostname Networking IP Address guestinfo.ipaddress Networking Netmask guestinfo.netmask Networking Gateway guestinfo.gateway Networking DNS Server guestinfo.dns Networking DNS Domain guestinfo.domain Networking



Step 4 - Power back on the VM and once it is available on the network (assuming DHCP), download and copy the sample first boot script rc.local to /etc/rc.d/rc.local. This script is where all the magic happens and will process the OVF property input and then configure the network settings. Right now it assumes these fields are optional, meaning if they left blank, it will default the system to DHCP. If you provide all input properties, then it will go ahead and configure a static network address.

Make sure the script has the executable permission by running the following command:

chmod +x /etc/rc.d/rc.local

Step 5 - At this point, the OS is now prepared and you can shut it down so we can export it to an OVF. To do so, you can either use OVFTool or simply use the vSphere UI by right clicking on the VM and select Template->Export OVF Template and download the respective files to your local desktop. Once you have the OVF, you can then convert it to an OVA using OVFTool which will give you a single image that you can easily distribute amongst your organization rather than a collection of files.

One limitation that I have found when exporting to an OVF is that the ordering of the OVF Properties is no longer maintained. If you want a particular ordering, especially for logical purposes, you will need to manually edit the OVF file prior to conversion. Here is a sample PhotonOS-Template.ovf file that you can use as a reference and if you decide to edit the OVF file, you will need to delete the .mf file which contains a hash of the originally generated OVF or the conversion will fail.

Step 6 - Next, run the following OVFTool command to convert your OVF to an OVA:

ovftool <OVF File> <OVA File>

Step 7 - Finally, the last thing to do is to try out our new PhotonOS OVA! Go ahead and run through the Import OVF wizard and you should now be prompted to input OVF properties. As mentioned earlier, the script is designed to handle zero input which means it will default to DHCP or if you specify all the properties, it will go ahead and configure a static network address. You can also use various CLIs like OVFTool or govc to import the OVA, but for testing purposes, the vSphere UI is ideal to ensure there are no issues.

Note: PhotonOS does not use the traditional netmask value (e.g 255.255.255.0), it expects the input to be CIDR notation (e.g. 24)



Once the VM starts up, the first boot script will automatically execute and once it has completed, it will create a file in /root/ran_customization which is checked by script to ensure it only runs once. For testing or debugging purposes, you can remove the file and the customization script will re-run again. Hopefully this example gives you a good idea on how you can customize your GuestOS which goes beyond networking but can manage other things like installing or reconfiguring an application at deploy time. Stay tuned for the last and final part of this short series where we will take a look at a reference implementation for building a Microsoft Windows VA which will include network configuration along with a popular OS configuration that is frequently asked by customers.