Home > Blogs > VMware vApp Developer Blog > Monthly Archives: March 2010

Monthly Archives: March 2010

The VMware Studio vApp Profile: Adding Existing OVFs

To create a vApp, VMware Studio uses a separate profile to specify the VMs to  include when constructing the  vApp, as well  as other various vApp-level parameters.


The  VMs  can  be specified  in  a  few  different  ways in  the  vApp profile. The relevant section in the XML looks something like this:


    <vadk:VMCollection>
        <vadk:VM
            vadk:ovfid="centos53"
            vadk:appurl="true"
            vadk:profile="centos53"
            vadk:location="http://[VADK.localIP]/build/centos53.1/exports/ovf/VM_OVF10.ovf"/>
        <vadk:VM
            vadk:ovfid="centos53 1"
            vadk:appurl="false"
            vadk:profile="centos53"
            vadk:location="http://[VADK.localIP]/build/centos53.1/exports/ovf/VM_OVF10.ovf"/>
    </vadk:VMCollection>

The vadk:ovfid attribute is a unique identifier for this VM. This will be used as a prefix to make any identical names in each VM unique. For example, the default Network label in a VM created by VMware Studio is called "Network 1".  In order for the VMs to be  able to have distinct networks, the   VM's   Network   labels  are   prefixed   with   the vadk:ovfid. Note that when vadk:ovfid is used to prefix filenames, any spaces in the vadk:ovfid will be replaced with underscores (_).


The vadk:appurl attribute is a boolean value  specifying that vCenter should use this VM's AppUrl value for the link in the Summary tab.


The  vadk:profile attribute  is  a pathname  to  the associated  build profile  for this  VM.  If  it  is solely  a filename  without an  xml extension (as it is here: centos53),  the filename is assumed to be in the     default    directory     where    profiles     are    created: /opt/vmware/var/lib/build/profiles/centos53.xml.    Note   that   this profile must  be configured  to produce an  OVF or  OVA as one  of its output formats (vadk:DistributionFormat).


The vadk:location attribute is where the location of an existing VM is specified. If vadk:location is empty,  then VMware Studio will use the value of  the vadk:profile attribute,  build the VM described  by this profile, and then include the resulting OVF or OVA in the vApp.


If the  vadk:location attribute is not empty,  it can contain one of several things:

  1. An absolute path (on VMware Studio) to a version 1.0 OVF or an OVA containing a version 1.0 OVF,
  2. A URL to a version 1.0 OVF or an OVA containing a version 1.0 OVF. In this URL, the keyword [VADK.localIP] may be used, and will be substituted with the actual IP address of the VMware Studio machine.


Note that the OVF or OVA specified does not need to have been built by VMware Studio. In particular, a  VM exported from vCenter can be used, as well as a third-party OVF or OVA. However, the use of a third-party OVF or  OVA is only supported on  a case by case  basis. VMware Studio cannot guarantee that the third-party OVF or OVA will combine properly into a vApp,  as the OVF specification is complex,  and it is possible that  a valid  OVF  may not  be  consumed by  the  VMware Studio  vApp building utility.


Let the VMware Studio team know of any difficulties you have with vApp construction, and we'll try to help.


vApprun, OVF 1.1, and ANSI/ISO Standards

In has been a while since the last update and a lot of exciting things has happens with regards to both OVFs and vApps in the meantime.

In the real code department:

I am very happy to annouce that  we just released our latest OVF-related fling on labs.vmware.comvApprun 1.0. This is a free, command-line tool that implements vApps and, OVF properties, and OVF environments for both Workstation and Fusion users. Thus, vApps are no longer just for vSphere 4. From the vApprun release notes:

A vApp is a container for a distributed, multi-VM software solution. It has power-on operations just as a virtual machine, and can be imported or exported as an OVF package. The OVF properties and OVF environment provides a flexible mechanism for parameterizing guest software inside a VM upon deployment. Using the OVF properties, it is possible to both configure OS level properties, such as IP settings, and application level parameters, such as IP addresses of external servers. The features of vApprun include:

  • vApps that contain multiple VMs and nested vApps.
  • For a vApp, the start/stop sequence of the child entities can be configured.
  • Start/stop/shutdown of vApps.
  • Create OVF properties and access the OVF environment from guest software.
  • Supports ISO and guestInfo OVF environment transports.
  • Supports fixed, transient, and DHCP IP allocation modes and IP pools.
  • Import OVF packages and run it with vApprun (using OVF Tool 2.0).
  • Export vApps and VMs created with vApprun to OVF packages (using OVF Tool 2.0).
  • Command-line, workspace-oriented user interaction.
  • Cross-platform – available for Windows/Mac/Linux.
  • VMware vSphere 4 compatible.

As a teaser, here is how to create a vApp with 2 VMs and a property:

>vapprun init
>vapprun create-vapp MyVApp
>vapprun create-vm VM1
>vapprun edit VM1 parent=MyVApp
>vapprun create-vm VM2
>vapprun edit VM2 parent=MyVApp
>vapprun def-property MyVApp key=ip type=ip:Network
>vapprun list MyVApp
Name.......: MyVApp
Type.......: vApp
IP Policy..: fixed
Children:
Name    Order StartWait WaitForTools StopWait
------------------------------------------------------------
VM2    30  30   True   30
VM1    30  30   True   30
Property Definitions:
Key      Type   Value      UserConfig
-------------------------------------------------------------------------------
ip      ip:Network         True
Property Settings:
Key      Value
------------------------------------------------
ip

You can download it here: vApprun 1.0 and start playing with vApps today. We will soon follow up with an more in-depth look at vApprun on this blog.

In the specification department:

The OVF  1.1 specification was released in January. This is a minor, fully backwards compatible update to the 1.0 specification. From the DMTF newsletter:

There are several new components that differentiate the OVF 1.1 specification from the original version, including:

  • Capability for file system-based images to increase flexibility at deployment time
  • A property attribute to hide password values at the user interface
  • Joliet extensions for ISO transport image
  • Clarification of how the OVF manifest contain entries for individual file chunks
  • Clarification of the referencing of manifest and certificate files from descriptor

In even more exciting news, the OVF 1.1 specification has been submitted to ICITS to become an ANSI standard, which is the first step to become an ISO standard. From the DMTF site:

DMTF has been busy extending and refining the Open Virtualization Format (OVF) specification. The organization recently completed version 1.1 of the spec and has submitted it for consideration as an ANSI and ISO standard.

This is an important milestone for DMTF. The specification will be put through a number of tests to ensure it meets a complex system of checks and balances of reviews before it is adopted as an American and International standard.

That is all the news for this time. Take care,

/Rene