Home > Blogs > VMware vApp Developer Blog > Tag Archives: Studio 2.0

Tag Archives: Studio 2.0

Updates for VMs created with VMware Studio 2.0

Introduction to appliances and updates

VMware Studio builds VMs. As
a part of VM building, VMware Studio 2.0 embeds an in-guest agent also known as
VAMI (Virtual Appliance Management Infrastructure) for Linux VMs, this in-guest
agent allows users to configure system parameters, example: timezone, configure
networking parameters, example: specifying ip addresses, and optionally update
the VM.

A VM with update agent
installed/enabled is considered to be a virtual appliance, and the user of the
appliance can update the appliance with a single-click. The update model
provided by VMware Studio for appliances is a pseudo-firmware model, where a
single update will update all the components (application packages) in the
virtual appliance. The update includes both OS updates, and updates for the application,
this ensures that an update applied to the appliance doesn’t break the
application.

Appliance builder can publish
updates easily using Studio 2.0, updates are published to an update repository as a part of an appliance
build. An update consists of a set of packages that are in native package
formats (i.e. either rpms or debs based on the Linux flavor), as a result
updates can be tracked using existing package managers, and as an appliance
builder updates for non-application packages (OS updates) are easier to find.

Publishing Updates for your Appliance

Updates are published during build

During the creation of a
build profile to build a VM, the appliance author specifies the list of
application packages and OS packages that are to be installed for the
appliance.

When Studio builds the VM, it
can determine all the packages that were installed on the appliance, Studio
uses this information to create an update repository as a part of the build.
The update repository contains a manifest file which lists all the packages
that were installed and a pool of packages. This update repository can then be
used for testing updates and once tested it can be published externally, so
that the appliances in the field can get their updates.

Enabling updates in Studio UI

While creating the build
profile for your appliance you can add the update management service to enable
updates for your appliance, once this service is enabled the build profile
wizard will ask you to enter additional details.

Note: To publish to the same update repository the appliance version needs to be incremented.

a) Repository Access Methods

Repo_settings
The appliance will use either a CD-ROM or will connect to
the specified URL to obtain updates. Later
on, the appliance user can also point to a local (alternate) repository to
obtain updates, this can be configured by the appliance user using VAMI web
console.

b) Repository Server Settings

Repo_server

As a part of the build, Studio will
create an update repository at the specified location using the SCP information
entered. Repository server is usually the staging server (see next section for
more information) for the appliance updates.

c) Repository Export Settings

Repo_export

If you’d like to save a copy of the
update repository in either zip format, or create a CD-ROM based repository that
can be used to update the appliance it can be specified here.

Please refer to Studio
Developer's Guide documentation for more information.

Staging Server

A staging server is usually a
location within the organization. This location is used by Studio to publish
the updates during appliance build. This repository can also be used to test
the update before releasing the update.

Advanced Option – Update scripts

Studio provides ability for
the author of the appliance to specify scripts that can be run before or after
installation of packages (i.e. rpms or debs). A good example of such a script
would be: deletion of a package which already is present in the VM and would
cause conflict with a package in the update.

To edit these scripts, open
the build profile using an XML editor (located at
/opt/vmware/var/lib/build/profiles directory in the Studio VM), and change the
default content of <vadk:PreInstallShellScript> and/or  <vadk:PostInstallShellScript> under
section “vadk:UpdateSection_Type”.

Note: Scripts added will
have to be XML encoded to ensure that it is valid XML.

Updating your Appliance

The appliance can be updated
by the appliance user using either the VAMI Web Console, CLI on the appliance,
or using vSphere Client/vCenter.

Web Console

Using the VAMI web console,
the appliance user can check for updates, update the appliance, schedule
automatic updates, and specify alternate methods of obtaining updates.

If updates are being received
from an external repository then the user simply clicks on the Check button to
query if any updates are present, and if there are any updates present user
clicks on the Install button to update the appliance.

If an update is received as a
CD-ROM ISO file, then the user can attach the ISO file to the CD-ROM device of
the appliance, and run check/install operations as a user would for an external
repository.

CLI

Studio in addition provides
vamicli, a command line tool on the appliance, using which the appliance can be
updated.

Please refer to Studio User’s
Guide
for more information.

Testing Updates

It is recommended that the
author of the appliance, test updates before releasing the update to the
appliance users. In order to test the appliance which is built with an external
repository URL, the author can deploy the appliance inside the organization,
and change the repository URL to the staging server URL or use a CD-ROM based
update using the VAMI web console.

Integration with vCenter for centralized update
management

VMware vCenter Update Manager
a vCenter plugin allows users of appliances (built with VMware Studio) to
update their appliances. The remediation process during which the appliance is
update can either be started manually or as a scheduled task. With Update
Manager multiple appliances can be updated at the same time, when an appliance
boots up VMware Update Manager automatically discovers that the VM has VMware
Studio’s update agent in the VM and allows users to scan and remediate
appliances. 

Users can also define
baselines. Baselines are rules that the administrator of an appliance can
define using Update manager, an example would be: an appliance must always be
at the latest version. Using baselines the administrator can check appliances
for compliance.

More information on how to
use Update Manager can be found in the Studio User’s Guide.

Have fun publishing updates for your appliances!

 


Configuring OVF Properties through VMware Studio 2.0

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.

 In order to see Studio’s support for OVF properties in
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:

  • Allow
    users to choose either DHCP or Static networking for VM/vApps during
    deployment.
  • Allow
    users to select Transient IPs (or a pool of IPs which can be configured in
    vSphere and used as an alternative to Static IPs)
  • Allows
    authors to restrict the IP Allocation policy to either DHCP or Static/Transient,
    or all three.
  • Configure
    networking for all Linux VMs, even those which are part of a vApp.
  • Reduce
    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
2.0.

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

Additional OVF properties automatically supported
by VMware Studio that you may find useful are:

  • 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.
  • vami.timezone:
    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.
  • vami.hostname:
     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

Studio
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

/opt/vmware/share/vami/vami_ovf_process –printovfenv

Or by simply looking up file:

/opt/vmware/etc/vami/ovfEnv.xml
(not present in Studio 2.0 beta)

Other possible uses

OVF properties can be broadly classified into two types from
a deployer’s perspective:

User Configurable

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.

Non-User Configurable

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.

More links:
VMware Studio 2.0 Overview
VMware Studio 2.0 Beta webinar recording
VMware Studio 2.0 Beta podcast