Previous blog post "Self-Configuration and the OVF Environment" introduced the concept of OVF Environment
and how an author of a VM or a vApp can provide deployment options to configure
a VM or a vApp using OVF properties. These OVF properties can be common to all
VMs, for instance IP configuration, and others which are application specific.
For example: An application which has a notification mechanism may require an
email address, OVF properties can be used to ask the deployer of the VM to
enter the administrator’s email address.
Studio supports creation of user defined application
specific OVF properties, creates network related properties for VM by default, and
provides an in-guest agent (glue code) for Linux VMs to configure the network
information for the VM.
Application specific OVF properties specified for a VM/vApp
in Studio requires an in-guest script which can consume these properties. This
script would parse the key/value pairs of the OVF environment and configure the
application accordingly. This script can be installed as a package
(rpm/deb/vsp) in the VM and invoked as a part of the boot customization (firstboot
script) provided in Studio.
action, OVF 1.0 VM/vApps (or OVA) generated by Studio 2.0 and vCenter 4.0 is
required. OVF environment is not present in the guest OS while deploying on ESX
4.0 directly or if OVF 0.9 is being used.
IP related OVF properties
The previous blog entry gave a quick overview of defining static
IP properties and using these IP related properties to configure your VM.
Studio provides support for network properties out of the box.
With Studio you can:
users to choose either DHCP or Static networking for VM/vApps during
users to select Transient IPs (or a pool of IPs which can be configured in
vSphere and used as an alternative to Static IPs)
authors to restrict the IP Allocation policy to either DHCP or Static/Transient,
or all three.
networking for all Linux VMs, even those which are part of a vApp.
the amount of information that needs to be asked. Studio uses dynamic
properties, so that entering common network information like subnet information;
gateway etc can be avoided for each VM.
In the Output tab of the Studio build wizard, the OVF IP Allocation/Assignment
Scheme determines if the user will be allowed to use Static or DHCP networking
for the application. If the OVF environment option is checked then the user is
presented with a choice of using Static or Transient IPs during deployment. If
DHCP is the only IP Allocation Scheme selected then the user is not prompted to
specify information for any networking related OVF property generated by Studio
When the user selects Static IP during deployment, the user
is prompted to enter only the IP address for that VM. The rest of the
information to configure the networking, the subnet mask, gateway, dns servers
are retrieved from a construct in vCenter 4.0 called IP Pools. To create an IP
Pool click on the datacenter in vSphere Client where the VM is being deployed and
select the IP Pool tab, now click on Add link in the tab. Here specify the IPv4
subnet, gateway, and optionally DNS servers. An IP pool is associated with
networks, during deployment of a VM a network should be selected, ensure that
this IP pool is associated with that network.
Transient IPs are similar to Static IPs but the user doesn’t
have to enter an IP address. The address is retrieved from a range of IP
addresses from IP pools in vCenter. In the IP pool configuration click on
Enable IP pool, and enter ranges of IPs that are reserved for VMs. vCenter
manages the IPs by allocating them on demand.
If there is a DHCP server on the network then specifying the
one exists on the network, in the IP pool configuration is recommended.
When you build a vApp from VMs which were created using
Studio 2.0, the networking properties are re-configured, so that all the VMs in
the vApp have valid networking properties.
Other OVF properties
- vm.name property
which contains the name of the VM, this is a VM specific property. It is
useful in vApps, each VM can identify itself based on this property. This
property is present in all OVFs generated by Studio.
Studio provided in-guest agent configures timezone for a Linux VM if it
sees this property have a valid timezone string. This property is
available in the default template for vApps. For VMs, it needs to be
explicitly added to the OVF Properties section in Output tab.
This property is used to configure
the hostname for a Linux VM. For those VMs which are going to be
configured with Static IP and require a valid hostname to be specified, it
is recommended that this property be used to specify a hostname. This
property needs to be explicitly added to the OVF Properties section in
Output tab. (not supported in Studio 2.0 beta).
Accessing OVF Enviroment
packages VMware Tools for all VMs that are built, as a result the transport of
OVF environment to the guest uses VMware Tools. The OVF environment can be
accessed within Linux VMs using either the command
Or by simply looking up file:
(not present in Studio 2.0 beta)
Other possible uses
OVF properties can be broadly classified into two types from
a deployer’s perspective:
This is best used to prompt user for inputs and configure
the application. To make a property user configurable make sure that the user
configurable option is set to true when defining a new property.
Some OVF properties are dynamic in nature, i.e. the values
for these properties are provided by vCenter dynamically. In order to specify
such properties a valid vmw: tag must be specified, this can be achieved by defining
a property as custom datatype. Example: To access vCenter IP Address you can
use the vmw qualifier VimIp("").
Other class of non-user configurable OVF properties is
static properties. They are similar to user configurable properties in all
aspects except the user will not be prompted to enter values during deployment.
They can be used to control application behavior. For instance, if you want to
control the verbosity of the application log or set values for application
timers to control application behavior on various deployment scenarios.