WilliamLam.com

You are here: Home / Automation / An alternate way to inject OVF properties when deploying virtual appliances directly onto ESXi

An alternate way to inject OVF properties when deploying virtual appliances directly onto ESXi

by // 13 Comments

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.

To demonstrate this functionality, I have created two sample scripts: setOvfEnv.pl (vSphere SDK for Perl) and setOvfEnv.ps1 (PowerCLI)

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.

alternate-method-injectovf-0
Here is an example of the VCSA OVF XML:

<?xml version="1.0" encoding="UTF-8"?>
<Environment
     xmlns="http://schemas.dmtf.org/ovf/environment/1"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:oe="http://schemas.dmtf.org/ovf/environment/1"
     xmlns:ve="http://www.vmware.com/schema/ovfenv"
     oe:id="vcenter55-1"
     ve:vCenterId="vm-273">
   <PlatformSection>
      <Kind>VMware ESXi</Kind>
      <Version>5.5.0</Version>
      <Vendor>VMware, Inc.</Vendor>
      <Locale>en</Locale>
   </PlatformSection>
   <PropertySection>
         <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"/>
   </PropertySection>
   <ve:EthernetAdapterSection>
      <ve:Adapter ve:mac="00:50:56:a8:c3:d4" ve:network="access333" ve:unitNumber="7"/>
   </ve:EthernetAdapterSection>
</Environment>

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.

alternate-method-injectovf-1
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.

alternate-method-injectovf-2
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.

alternate-method-injectovf-3

alternate-method-injectovf-4

alternate-method-injectovf-5
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.

More from my site

Comments

  1. > Though this is a neat “hack” to get OVF properties working when deploying directly to ESXi
    >

    My sole goal was bootstrapping an unmanaged ESXi node to managed-by-self-hosted VCSA, so I needed something which could be accomplished without making many in-VM changes to VCSA.

    Using the guestinfo.ovfEnv injection technique gets the VCSA up and configured sufficiently network wise that I can scp-in the second-round script to the VCSA local filesystem, and kick it off.

    Reply

  2. I am trying to automate the deployment of vCAC 6.0 SSO and VA appliances using the ovftool.exe command inside a PowerCLi script using the below command to import the appliance onto a standalone ESXi host. But for some reason the script does not do anything.

    $VA1 = "L3_VCAC-SSO"
    ovftool.exe -ds=Lun1 -dm=thin --net:Network 1="HQ Site" --name=$VA1 "B:\vCAC6.01\VMware-Identity-Appliance-2.0.1.0-1545089_OVF10.ovf" vi://root:[email protected]/vCloud | Out-Null

    I have used the above methods to deploy other types of appliances in the past but for some reason the vCAC VAs just wont play ball.

    Could you please shed some light on what am I doing wrong here?

    Thanks
    MP

    Reply

  3. Thanks William, this was really helpful.

    I have one question that if I am having password as one of the property field in my ProductSection, and at the time of deployment of my virtual appliance I am providing a password. Then I am using vmware tools to get my environment values inside my VM and then setting them appropriatly. But I don't want my password to be in plain text. Do you have any suggestions in this? What additional steps are you talking about?

    Thanks
    Prakash

    Reply

  4. Unfortunately , after editing the OVF environment also... while cloning the Vapp its not updating

    Reply

  6. Hi Bill,
    I am working on vcenter server 5 standard. I am generating an OVA using vsphere client. Since OVA is a tar file, unauthorized user can get hold of the software. So i am looking at solutions to prevent this.

    I could protect the tar file by using gcrypt however it will involve additional step of decrypting before deploying in vcenter or workstation.

    Are there any other means to protect the OVA while still retaining the simplicity of deployment ?

    I see that vcenter is generating OVA using OVF version 1.0 however OVF version 2.0 does have defined something for package protection.

    There does not seem to be information available on web about VMWare product that can generate 2.0 OVF...

    Any clues regarding this?

    Reply

    • Even ovftool 4.x does not have options to protect OVA (except signing which is to ensure integrity of OVA not to protect OVA)

      Reply

  7. Hi William

    do you think this should also with the deploying Orchestrator 6.0.x?

    following you guide very close and i;m getting

    â?oguestinfo.ovfEnvâ?? : The term 'â?oguestinfo.ovfEnvâ??' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

    any ideas?

    Reply

  8. Hi William

    Thanks for interesting article, I somehow managed to reach similar functionality via using guestinfo as a transport to pass configuration to coud-init, and now looking into a way to employ ovfEnv for the thing.

    What I like is OVF allows params to be configurable via UI, that's a nice one!

    I found few drawbacks with ovfEnv though and I can't find a way to get around them. Specifically, when using any other guestinfo property and updating it via API, I see the value change in the guest immediately, while for ovfEnv I can't change the values in vSphere untill i power down the guest

    Another trick is updating the ovfEnv via API (i'm using perl sdk) doesn't seem to really work. The XML is simply not being updated, so the only way to change the env is via vsphere gui really for me

    Unfortunately when i try to install ovftool I get nothing but a crash of my window manager (we are using debian jessie), so I can't really even install ovftool sadly and see if that helps me.

    So questions are really:
    - how do i update ovf properties via SDK?
    - is ovftool able to do that?
    - Is there a way to update ovfEnv while guest is running?

    These are what stops me from using ovf environment, I'd love to use it instead of reinventing the wheel (but so far my wheel works better that ovfEnv)

    Thanks a lot for your time, even if you may not have all the answers, I'd love to hear your thoughts!

    Reply

Thanks for the comment!

This site uses Akismet to reduce spam. Learn how your comment data is processed.