I recently published an article demonstrating how to inject OVF properties into the VCSA and other virtual appliances when deploying directly onto ESXi using an unreleased version of ovftool (4.0). A fellow reader by the name of VirtualJMills, as he is known on Twitter left an interesting comment using an alternate solution which I thought was actually pretty clever!
The solution that he had used prior to finding my article was to append the OVF XML payload which contains the OVF properties into an advanced VM Setting called "guestinfo.ovfEnv" which in turns makes the information available to the virtual appliance through the OVF runtime environment. Instead of manually editing the VMX file by hand (which is a big no-no in my opinion. Read more about it here) and painfully crafting the XML blob with the appropriate escape characters, one can easily automate this using the vSphere API! In fact, I had written an article about this very topic back in 2012 for accessing the advanced settings of a VM and I even provided vSphere SDK for Perl and PowerCLI samples scripts.
Disclaimer: Though this alternate method may work, it is still pretty manual and potentially error prone and it is still recommended to either deploy an OVF/OVA directly to vCenter Server OR by leveraging ovftool.
Before you can use these scripts, you will need to capture the OVF XML that is passed into the guestOS and add that to the script. To do so, you will need to manually deploy the virtual appliance against a vCenter Server for the first time to capture this information. Once the virtual appliance has been deployed, you will need to power it on and copy the OVF XML by click on Edit Settings->Options->OVF Settings->View.
<?xml version="1.0" encoding="UTF-8"?>
<Property oe:key="vami.DNS.VMware_vCenter_Server_Appliance" oe:value="172.30.0.100"/>
<Property oe:key="vami.gateway.VMware_vCenter_Server_Appliance" oe:value="172.30.0.1"/>
<Property oe:key="vami.hostname" oe:value="vcenter55-1.primp-industries.com"/>
<Property oe:key="vami.ip0.VMware_vCenter_Server_Appliance" oe:value="172.30.0.79"/>
<Property oe:key="vami.netmask0.VMware_vCenter_Server_Appliance" oe:value="255.255.255.0"/>
<Property oe:key="vm.vmname" oe:value="VMware_vCenter_Server_Appliance"/>
<ve:Adapter ve:mac="00:50:56:a8:c3:d4" ve:network="access333" ve:unitNumber="7"/>
If you have more than one virtual appliance deployed in your environment using OVF properties, you will see additional entries. Depending on the solution, you can strip it further down by removing unnecessary entries like EthernetAdapterSection. Once you have the XML, you can then add that to one of the scripts. In this example, we will use the PowerCLI script to configure a vCenter Server Appliance and the script already contains the minimum entry for configuring the VCSA. If you plan on automating other virtual appliances, remember to escape the double-quotes by using tick mark `.
Before running the PowerCLI script, you will need to edit the $esxname and $vmname variable along with substituting the OVF values in $ovfvalue variable. Once the script has completed, we can easily confirm guestinfo.ovfEnv was added by checking the .VMX file.
Once we have verified the guestinfo.ovfEnv advanced setting has been configured, we can power on the VCSA and the OVF properties can now be accessible from within the guestOS which we can confirm by watching the VM console of the VCSA.
As you can see from the screenshot above, the OVF values that we had configured has now been passed into VCSA and this allows you to deploy a virtual appliance directly onto an ESXi host and have the virtual appliance be properly configured without the need of a vCenter Server (for the most part).
Similarly, we can also do the same using the vSphere SDK for Perl script by editing the $ovfValue variable. In that sample, I have decided to configure the latest Log Insight 2.0 release and here are a couple of screenshots following the same workflow as the VCSA.
As mentioned earlier, even though this method works it is also very error prone due to all the manual steps. In addition, for virtual appliances that require a password, you are also exposing plaintext passwords in the guestinfo.ovfEnv and you would need to perform an additional step to null out the value after the virtual appliance has finished configuring. There are also other virtual appliances which have a reliance on vServices which is only exposed in vCenter Server and this method may not work with those type of solutions. Though this is a neat "hack" to get OVF properties working when deploying directly to ESXi, I would still highly recommend using ovftool to properly set these parameters.