VE on VMware - Part 1 - Custom Properties

Overview

BIG-IP v13.1.0.2 introduced support for injecting configuration options into a BIG-IP Virtual Edition (VE) at deployment time. This functionality allows you to specify the management IP, management gateway, and non-default credentials. As a result, you can now perform completely automated deployments of VE in a VMware environment.

Options Prior to BIG-IP v13.1.0.2

Previously, it was not possible to specify the management addressing and root / admin credentials at the time of VE deployment in a VMware environment. This might seem like a small issue, except that some production environments do not offer DHCP leases on their management networks. The prior options for securing a VE at deployment went a bit like this:

1. Deploy the VE, and rely upon our default management IP of 192.168.1.245 for initial connectivity. This means that you can safely deploy one VE at a time.
   ... or ...
2. Deploy the VE without management connectivity, then connect using a virtual console and configure management networking.
   ... or ...
3. Deploy the VE by connecting it to a management network with DHCP, then alter the management IP to match the final deployment environment. Complete the process by changing the attached networks for final deployment.

In addition, you could not inject non-default credentials for the root / admin users at the time of instantiation. Secure production environments probably used the virtual console or redeployment options.

New Functionality

We have an ongoing project, dare I say driving mission, to perfect our automated deployment options. The goal is to allow for complete automation of the deployment of VE on any of our supported hypervisors. Our approach to improving the VMware deployment process involves open-vm-tools and the handling of custom guest properties within the deployed image. The result is that there are now four properties that can be injected into an OVA / OVF at the time of deployment.

 

An important point of order: these empty properties must be injected into the OVA in order to be populated. The default OVA that you download from our public repository does not contain these properties. The empty properties are not in the published image due to ESXi compatibility issues. That said, adding the empty properties to the OVA is quite simple.

 

How It Works

The list of tasks:

1. Copy the OVA to a machine with enough free space (at least 2x the size of the OVA).
2. Use the Common OVF Tool (cot), or any tool that you are already familiar with, to add empty properties to the OVA.
   Example:

   cot edit-properties source-filename.ova -p net.mgmt.addr=""+string -p net.mgmt.gw=""+string -p user.root.pwd=""+string -p user.admin.pwd=""+string -u -o destination-filename.ova
   

3. Use VMware's ovftool, or your API of choice (example: pyvmomi), to inject values into the properties during deployment. You could also do this in the VM settings portion of the vCenter web interface, but we're aiming for a hands-free deployment. In the end, use the tool that feels the most familiar.
   Example:

   ovftool \
   --sourceType=OVA \
   --acceptAllEulas \
   --noSSLVerify \
   --skipManifestCheck \
   --X:logToConsole \
   --datastore='my_datastore' \
   --name='my_vm_name' \
   --vmFolder='my_vm_folder' \
   --deploymentOption='(any of the pre-define options in the OVA, such as "dualcpu")' \
   --net:'Internal=your_internal_network' \
   --net:'External=your_external_network' \
   --net:'HA=your_ha_network' \
   --net:'Management=your_management_network' \
   --X:injectOvfEnv \
   --prop:net.mgmt.addr="" \
   --prop:net.mgmt.gw="" \
   --prop:user.root.pwd="" \
   --prop:user.admin.pwd="" \
    \
   "vi://(your user@domain):(your password)@(your vcenter host)/(your DC)/host/(your cluster)"
   

4. Deploy the guest to your VMware environment.
5. Confirm a successful deployment, and start the guest.
6. After a successful boot-up, the VE will now have an L3 presence on the management network and non-default credentials.

What's Next?

The next article of this series will describe a simple Ansible playbook for automating this process, and deploying the VE without any personal involvement. It can be found here.