Author Archives: Rene W. Schmidt

How to run Zimbra on Fusion with vApprun

Updated: To work with the latest version of the Zimbra virtual appliance (Sep. 6). 

The Zimbra folks have been so nice to create a virtual appliance that contains the entire Zimbra Collaboration Suite. The Zimbra virtual  appliance is packaged up in the OVF format and is using several advanced vSphere features (such as OVF properties) to  simplify the entire installation. In fact, if you have vSphere 4, it is a  really simple process to get Zimbra up and running.

But what if you don't have access to vSphere 4? (or just want to try it out on your laptop while eating lunch?)

In this post, I will show how you can use the freely available tools, OVF Tool 2.0.1 and  vApprun 1.0 to deploy, configure, and run the Zimbra appliance on VMware Fusion or VMware Workstation. Basically, we are tricking Workstation/Fusion to think it has all the nice OVF capabilities from the full-fledged vSphere product.

So before we start the pre-requisites are:

  • An installed version of VMware Fusion 3 or VMware Wokstation 7
  • VMware OVF Tool 2.0.1 (download)   
  • VMware vApprun 1.0 (download)      

Make sure that both OVF Tool and the vApprun command is in your path.

Step 1: Create a vApprun workspace

The vApprun tool implements a complete OVF / vApp environment for Workstation and Fusion. To use vApprun, we need to setup a vApprun workspace:

>mkdir zimbra
>cd zimbra
>vapprun init

Step 2: Configure the IP Pool

Each vApprun workspace has an IP pool that stores the network settings and other information about your deployment environment. We set that up as follows:

>vapprun workspace "dns=;" 
IP Pool settings:
  dns =;
  domainName =
  gateway =
  hostPrefix = vapprun-
  httpProxy =
  netmask =
  range =
  searchPath =
Free IP addreses,,,

Make sure to substitute the values shown for DNS, gateway, netmask, and range with values that work in your environment.

Note 1: The above command should be executed as a single line. It has only been broken into multipe lines, so it is easier to read. The quotes ("") are only needed on Windows.

Note 2: If you are lazy and are on a network with a DHCP server, you can skip this step! (see step 5)

Step 3: Download the Zimbra Virtual Appliance

To download the Zimbra Appliance, open a web browser and go to:

You are required to fill out a registration form in order to get access to the appliance. 

Simply fill out the form, submit it, and you will receive an email with download 

instructions. Once you get the email, click on the download link (under Download Information)

to go to the download page. 


On the download page, copy the link listed 

as: vSphere 4.0+ (Open Virtualization Format 1.0) – Direct Import URL.


Step 4: Use OVF Tool to deploy to vApprun workspace

Now it is time to download and deploy the ZImbra Appliance into our vApprun workspace.

>ovftool "–name=zimbra" <<Paste URL from above here>> .
Opening OVF source:…/ovf/zimbra.ovf
Warning: No manifest file
Opening vapprun target: .
Info:    End User License Agreement


     … abbreviated …

Accept end-user license agreement?
Write 'yes' or 'no' (write 'read' to reread the EULA): yes
Deploying to vapprun workspace at: c:\Temp\zimbra\zimbra
Disk Transfer Completed
Completed successfully

Make sure to replace the URL in the above command with the one you got in Step 3. 

Notice that we just use a dot (.) as the target location. We can do that since the current directory is the vapprun workspace directory. 

Let's check that we got a Zimbra VM in our vApprun inventory:

>vapprun list zimbra
Name.......: zimbra
Type.......: VM
VMX........: .../zimbra/vmx/vm.vmx
Tag........: Zimbra_Collaboration_Suite_Appliance
AppUrl.....: http://${vami.ip0.Zimbra_Collaboration_Suite_Appliance}/
Transport..: com.vmware.guestInfo
IP Policy..: fixed
Property Definitions:
Key            Type      Value           UserConfig
Zimbra_CONFIG_PASS    string(6..20)               True
Zimbra_HOSTNAME      string(1..65535)              True
Zimbra_ADMIN_EMAIL    string(1..65535)              True
Zimbra_ADMIN_PASS     string(6..20)               True
Zimbra_DISABLE_FW     boolean     False           False
Zimbra_DISABLE_NETWORK_TAB boolean    False           False
Zimbra_SERVICES      string     ALL            False
Zimbra_LDAP_MASTER_IP   string     @@LDAP_MASTER_IP@@     False
Zimbra_LDAP_MASTER_URL  string     @@LDAP_MASTER_URL@@    False
Zimbra_VAMI_USER     string     @@ZIMBRA_VAMI_USER@@    False
Zimbra_VAMI_PASS     string     @@ZIMBRA_VAMI_PASS@@    False
Zimbra_MTA_AUTH_HOST   string     @@MTA_AUTH_HOST@@     False
Zimbra_HYPERIC_HQ_HOST  string     @@HYPERIC_HQ_HOST@@    False
Zimbra_HYPERIC_HQ_USER  string     @@HYPERIC_HQ_USER@@    False
Zimbra_HYPERIC_HQ_PASS  string     @@HYPERIC_HQ_PASS@@    False
vami.DNS0.Zimbra_Collaboration_Suite_Appliance expression   ${dns:Network}    False
vami.gateway0.Zimbra_Collaboration_Suite_Appliance expression ${gateway:Network}  False
vami.netmask0.Zimbra_Collaboration_Suite_Appliance expression ${netmask:Network}  False
vami.ip0.Zimbra_Collaboration_Suite_Appliance ip:Network              True
vm.vmname         string     Zimbra_Collaboration_Suite_Appliance   False
Property Settings:
Key            Value
... abbreviated ...

We need to configure the 4 properties listed under Property Settings (with value:
CHANGE-ME). We also need to decide how we allocate an IP address to the appliance. We can  setup the IP property to be configured from vApprun's IP pool (transient), using DHCP, or enter a fixed address. All in all this amounts to the following command:

>vapprun set-property -transient zimbra

If you want to use DHCP, replace the -transient option above with the –dhcp option in the above command. And a

gain, the above command should be typed in as a single line.So let's double check that we did everything right:

>vapprun list zimbra
… abbreviated …
IP Policy..: transient

Property Settings:
  Key                       Value
  Zimbra_ADMIN_PASS         secret
  Zimbra_CONFIG_PASS        secret
  Zimbra_HOSTNAME           zimbra-host
… abbreviated …

Step 5: Launch Zimbra 

The moment we have been waiting for… let's start it:

>vapprun start -gui zimbra
Starting zimbra
Access at:

The Zimbra appliance takes a few minutes to go through the first-time boot configuration. Once it is up and running, you can access the appliance at the URL above. To login use the admin email and password you configured in step 5 (, secret).

Note: If you are using DHCP, then vApprun does not know at the time of power-on what IP address will be used, so the Access at: message will not be shown. Instead, run the vapprun list command to see what IP address has been allocated to the VM. This is reported back to vApprun through VMware Tools.



Once you have done the above steps a few times, it actually becomes quite simple. Finally, all of the above works equally well on Mac OS X, Windows, and Linux.


OVF Tool 2.0.1 is now available for download!

We are happy to announce that OVF Tool 2.0.1 was released yesterday. It can be downloaded from here, and is available for Windows, Linux, and Mac OS X (new!). 

This is the first major release since the initial release of OVF Tool 1.0 and a minor upgrade to the OVF Tool 2.0 version that is bundled with Fusion 3.1 and Workstation 7.1. I have included an excerpt from the README below which describes the changes:

Changes since 2.0.0
. Fixed bug that caused OVF Tool not to work with the “Import from vSphere”
feature on the VMware Virtual Appliance Marketplace.
. Fixed launch issue on Linux/Mac if installed in a location where the path
includes spaces.
. Fixed issue with properties when importing to vApprun workspace.

Changes since 1.0.1
. Support for the OVF 1.1 specification.
. Support for OVF packages that includes ISO and floppy images.
. Support for vApprun as target and source.
. Support for OVF Tool on the Mac OS X operating system (Intel-only).
. A lax mode (–lax) that enables a best-effort conversion of OVF
packages which do not fully conform to the OVF standard or include
virtual hardware that is not supported by the destination. For example,
VirtualBox (version 3.0 and 3.1) produced OVF packages can be converted in lax mode.
. Bug fix for handling vmxnet3 targets.

Please use the forum on the download page to post any comments or issues with the tool. We would like to hear to hear from you.


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
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

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,


Inside the OVF Package

In the previous blog posts we have talked how OVF packages can be deployed using the vSphere client and OVF Tool, and how to use OVF to create self-configurable virtual machine templates. In this blog post we will look inside an OVF package to see how it is structured and organized.

OVF is an open standard developed by the Distributed Management Task Force (DMTF) with cooperation from VMware, Citrix, IBM, Microsoft, Sun and other companies. The standard has arisen to meet the growing demand from industry to create a portable format for virtual machines that is vendor and platform independent.  The goal of OVF is to provide a standard format that can robustly and efficiently deliver software solutions inside a set of virtual machines. The OVF format needs to be extensible and flexible enough to be able to serve the needs of describing a simple single VM image as well as describing the next-generation, dynamic applications for the cloud. In this blog entry, we will discuss the basic file structure of the OVF package, as well as many of the extensibility features built into the format.

On the configuration side, OVF 1.0 standardizes the basic settings for a hypervisor, including virtual hardware, disks, networks and resource allocation. An OVF package can also carry additional meta-data, including:

  • Product information that describes the software installed in the virtual machines, this covers both operating systems and application level components
  • End-user-license agreements (EULA)
  • Self-configuration parameters and deployment options for customization at deployment time

Ok, let's dive into the technical details to see how all this is achieved. We will cover three main areas: File layout and integrity, disk formats and compression, and the OVF descriptor and extensibility.

File Layout and Integrity

An OVF package consists of an OVF descriptor, a set of virtual disks, a set of localization bundles, a manifest, and a certificate (some of these are optional). For example:


The OVF descriptor (.ovf) is the main document of an OVF package. It contains all meta-data for the OVF package and has links to external files, such as virtual disks. We will get back into how this is structured in a moment.

The manifest (.mf) and certificate (.cert) files are optional and are used for integrity and authenticity checks. The manifest file contains the SHA1 digest of all files in the package (except for the .mf and .cert files themselves), and the certificate file contains a signed digest for the manifest file and an X.509 certificate. If present, they must be in the same directory as the OVF descriptor and have the same base name. We will skip string bundles for localization for now, that is a topic for a future blog entry.

An OVF package can be distributed as a set of discrete files as shown as above. For example, they can be uploaded to a web server and the URL to the OVF descriptor (.ovf) can be emailed to the recipients. However, often it is convenient to distribute a single file. The OVF specification defines a standard archive called an Open Virtualization Format Archive (.ova) exactly for this. This format is a "tarball" of the individual files that makes up the OVF package (with certain restrictions). For example:

If you get an OVA package, try running tar tf <name>.ova and you can see the content. You can also create OVAs using the tar tool (or the OVF Tool or vSphere Client, of course). However, keep in mind that the OVA format is not simply a tar. It places certain restrictions on the ordering and naming of files. In particular, the OVF descriptor (.ovf) must be the first file and the files must be listed in the tar archive in the same order as they are listed in the OVF descriptor (see the OVF specification for all the details). These rules ensure that OVA archives are easy to stream – a tool or hypervisor does not need to download an entire OVA first and then unpack it.

Disk Formats and Compression

An OVF package is intended for distribution, so compression is the next big issue after ensuring package integrity. The granularity of compression is per file and works for both OVA archives and multi-files (.ovf) archives.  In other words, you don't need to create an OVA to get file compression.

In the OVF descriptor, you can specify compression options on each external reference, such as a string bundle or an ISO file (using the compression attribute in the Reference section). The most important part to compress is the virtual disk files. All OVF packages generated by VMware products utilize a variant of the VMDK format that is especially designed for distribution and already compressed; this is called the stream-optimized format. In this format, the content of a disk is stored, by default, in 64KB compressed chunks and only non-zero chunks are included. The format is designed so it is efficient to both consume and generate on the fly, as well as being able to provide good feedback on progress while being downloaded.  

Note that the VMDK format used for a deployed VM can and and typically will be different from the stream-optimized format. For instance, when deploying on ESX, the flat VMDK format is often used. The conversion from the stream-optimized format (used in the OVF package) to the flat VMDK format (used at runtime) is seamlessly done as part of the import step and is performed on the fly as part of the download process.

OVF Descriptor and Extensibility

Having covered the basic file level infrastructure, compression and integrity checking, let's take a look at the OVF descriptor (.ovf). The OVF descriptor is an XML document that stores or links to all information about the software contained in the OVF package. The purpose of the OVF descriptor itself is to provide the basic structure for embedding and discovering application meta-data. The outer most tag in the OVF descriptor is named Envelope, since the OVF descriptor is, in fact, modeled after an envelope where a variety of notes can be put into.  The following outlines the structure of an OVF descriptor:

<Envelope xmlns="" … >
     <File ovf:href="MyPackage.vmdk" ovf:id="disk1" ovf:size="68608"/>
   … List of OVF sections …
   … A Virtual System or VirtualSystemCollection …
   … String bundle references …

Each OVF descriptor has a required section, called References, that lists all file in the package  (except for the descriptor itself, the manifest and the certificate files). In this way a tool can always check an OVF package for integrity or copy it, without understand the content of each file or the meta-data sections that has included the external file references.

The rest of the OVF descriptor is made up of two parts: Entities and OVF sections. An entity is either a VirtualSystem or a VirtualSystemCollection, describing a single virtual machine or a container of multiple virtual machines, respectively. The syntax for describing a virtual machine is simply:

<VirtualSystem ovf:id="myVm">
     <Info> User-friendly description of the purpose of
            this entity (e.g., it describes a VM) </Info>
     <Name> Display name of the VM </Name>
     … OVF Sections …

An OVF package can also contain more than one virtual machine. This is done using the VirtualSystemCollection element:

<VirtualSystemCollection ovf:id="myVapp">
     <Info> User-friendly description of the purpose of the entity
g., it describes a VM) </Info>

     <Name> Display name of the vApp </Name>
    … OVF Sections …
    … child entities – either VirtualSystem or VirtualSystemCollection …

The real meat of a VirtualSystem or VirtualSystemCollection is in the OVF sections. An OVF section is an XML fragment that contains the data for a specific functionality or aspect, such as virtual hardware requirements, operating system type, or maybe a dependency on an external system.  The general format of an OVF section is as follows:

<myns:MyOvfSection  ovf:required="true or false">
       <Info>A description of the purpose of the section</Info>
       … section specific content …

The fully-qualified element tag (myns:MyOvfSection in the above example) uniquely identifies the OVF section.  The ovf:required and <Info> elements are part of the extensible design for OVF. OVF is designed to handle both forwards- and backwards compatibility. An OVF-compliant product cannot be expected to know about all possible sections, since OVF sections can be created by third-parties or defined in newer versions of the OVF specification. The ovf:required  attribute tells whether a tool can safely ignore the section, or whether it must fail if it does not understand the section. The <Info> provides a user-friendly description of the section that can be shown to the user in either case. Note that ovf:required defaults to true, so commonly it is left out.

An example of a custom third-party section in an OVF descriptor could be:

<myns:IncidentTrackingSection ovf:required="false">
   <Info>Useful info for incident tracking purposes</Info>
   <BuildSystem>Acme Corporation Official Build System</BuildSystem>

The OVF 1.0 specification defines 10 core sections that cover the basic vApp information:

  • DiskSection: Information about all virtual disks in the OVF package
  • NetworkSection: Defines the network topology inside an OVF package
  • ResourceAllocationSection: Resource settings for a VirtualSystemCollection
  • AnnotationSection: A description or annotation on an entity
  • ProductSection: Information about the software installed in the guest, including  properties for self-configuration
  • EulaSection: An end-user license agreement
  • StartupSection: Defines the start-up and shutdown order for the children in a VirtualSystemCollection
  • DeploymentOptionSection: Defines a set of pre-defined configurations that can be selected at deployment time
  • OperatingSystemSection: Specifies the operating system installed in a guest
  • InstallSection: Specifies whether a guest OS needs to be booted once (or more) before the application is fully deployed

These sections are described in the OVF Specification. See DSP0243 for the details, as well as the accompanying XML Schemas DSP8023 and DSP8027.  The OVF whitepaper DSP2017 also includes many examples on how these are used. The set of OVF sections are expected to grow significantly as the OVF format gains traction. 

We have only dived a little into the OVF descriptor, focusing on the file layout and the overall structure. We have covered the basic features around distribution support and extensibility. In future blog posts, we will dive into specific areas, such as localization, virtual hardware description, delta-disk compression, custom OVF sections and extensibility, multi-VM encodings, and much more.  So until next time, keep deploying those vApps!

Command-line OVF Deployments

In the previous blog post, I showed how to deploy a multi-tiered OVF package using the Deploy OVF Template Wizard in the vSphere Client. The interactive workflow provided by the vSphere Client is hard to beat in terms of ease of use and simplicity. However, the graphical user interface also has it drawbacks. In particular, it can be fairly cumbersome to use if you have a large set of similar OVFs that needs to be deployed, or you want to automate a deployment. In those cases, a command-line utility is often preferred. Well, we have exactly the solution for that: OVF Tool 1.0.

OVF Tool provides a slew of different features, such as converting between OVF and .vmx formats and import/export of OVF 1.0 to vSphere 4.0, VirtualCenter 2.5/ESX 3.5 and earlier releases.

In the following I will show how to deploy the SugarCRM solution from the command-line and get exactly the same result as I got from the vSphere Client last week.

First, I probe the SugarCRM.ova to figure out what it contains and particular what parameters can be customized.

f:\>ovftool –hideEula http://aar-ovfrepo/ovf/SugarCRM.ova
Opening OVA source: http://aar-ovfrepo/ovf/SugarCRM.ova
OVF version:   1.0
Name:          SugarCRM
Version:       4.5.1e
Full Version:  4.5.1e-build 131
Vendor:        SugarCRM Inc
Product URL:
Vendor URL:

Annotation:  The sweet way to manage customer relationships.

End-user License Agreements:
  Present:     Yes (1)

Download Size:   764.49 MB

Deployment Sizes:
  Flat disks:     20.00 GB
  Sparse disks:    1.55 GB

  Name:        Network
  Description: The network that the SugarCRM application will be available on

Virtual Hardware:
  Family:       vmx-04
  Disk Types:   SCSI-lsilogic

  Key:         emailAdmin
  Category:    Application
  Label:       Administrator Email Address
  Type:        string
  Description: Enter email address for administrator. This is displayed on the help page.

  Key:         theme
  Category:    Application
  Label:       Theme
  Type:        string["Sugar", "RipCurl", "Retro", "Paradise", "Love",
  Description: Select the default color/graphic scheme

  Key:         concurrentSessions
  Category:    Performance
  Label:       Concurrent Sessions
  Type:        int(10..1000)
  Description: The maximum allowed concurrent sessions.

  Key:         dbIp
  Category:    Network
  Label:       Database instance IP address
  Type:        ip:Network
  Description: IP address for the database instance (in dot-notation).

  Key:         webIp
  Category:    Network
  Label:       SugarCRM IP Address
  Type:        ip:Network
  Description: IP address on the SugarCRM application server. The service is made accessible at this IP address.

Deployment Options:
  Id:          small
  Label:       Evaluation
  Description: Use this configuration for evaluation purposes on
ly. The number
of CPUs required and amount of memory used is minimized, making it possible to run the system on a desktop system.

  Id:          medium
  Label:       Production
  Description: Standard settings for a typical product environment. This deployment option is suitable for a SMB production environment with less than 500 users.

  Id:          large
  Label:       Enterprise
  Description: Settings for large enterprise production environments. This deployment option is suitable for a large enterprise production environment with more than 500 users.

IP Allocation Policy:
  Schemes:     ovfenv dhcp
  Protocols:   IPv4

Completed successfully

By examining this output, I can gather the same information as was shown in the vSphere Client, such as product information, download sizes, end-user license agreements, deployment options, properties that can be customized, and supported IP policy schemes.

The next step is to deploy this to my vSphere 4.0 server. OVF Tool provides a handy pseudo-interactive mode for probing the vSphere inventory, so I do not have to open the vSphere client to look up the inventory organization or names of networks and datastores. To get started, I simply try and deploy it:

f:\>ovftool http://aar-ovfrepo/ovf/SugarCRM.ova vi://aar-dev-cluster-vc1
Opening OVA source: http://aar-ovfrepo/ovf/SugarCRM.ova
Please enter login information for target vi://aar-dev-cluster-vc1/
Username: VMWAREM\renes
Password: *********
Error: Found wrong kind of object (Folder)
Possible completions are:   
  Jan's Test Datacenter/   

Ok, so the first completion is: vi://aar-dev-cluster-vc1/aar-dev-datacenter/. After a few more iterations, I get to this:

f:\>ovftool –acceptAllEulas http://aar-ovfrepo/ovf/SugarCRM.ova vi://VMWAREM%5Crenes@aar-dev-cluster-vc1/aar-dev-datacenter/host/Cluster/Resources/DemoPool
Opening OVA source: http://aar-ovfrepo/ovf/SugarCRM.ova
Please enter login information for target vi://aar-dev-cluster-vc1/
Username: VMWAREM\renes
Password: *********
Opening VI target: vi://VMWAREM\renes@aar-dev-cluster-vc1/aar-dev-datacenter/host/Cluster
Error: No target datastore specified
Datastores found on target:
  Cluster VMFS

It now provides completions for datastores. Simlilarly, OVF Tool will provide completions for networks (if there are multiple choices). The final command to deploy, customize, and power-on the SugarCRM OVF package is:

f:\>ovftool "–datastore=Cluster VMFS"
            "–network=VM Network"
Opening OVA source: http://aar-ovfrepo/ovf/SugarCRM.ova
Please enter login information for target vi://aar-dev-cluster-vc1/
Username: VMWAREM\renes
Password: *********
Opening VI target: vi://VMWAREM\renes@aar-dev-cluster-vc1/aar-dev-datacenter/host/Cluster/Resources/DemoPool
Target: vi://aar-dev-cluster-vc1/aar-dev-datacenter/host/Cluster/Resources/DemoPool
Disk Transfer Completed
Powering on vApp: SugarCRM
Completed successfully

Voila! (Standard disclaimer: I inserted a few line breaks to make it more readable. How to escape spaces in parameters varies whether you are on Linux or Windows).

This was just a very quick preview of the features of OVF Tool. Consult the documentation for more examples, and download the tool today to try it out for yourself. Next time,
I will dive into the internal structure of the SugarCRM OVF package.

OVF and vApps in Action!

The vSphere 4.0 release provides full support for the OVF
1.0 specification. This is a major upgrade compared to the OVF features
that existed in VirtualCenter 2.5 and ESX 3.5, which were based on the
preliminary OVF 0.9 specification and only included import and export
of single VMs. The new features include:

  • vApps – managing multi-tiered applications as a first-class entities in vCenter
  • A data-driven OVF Deployment Wizard to greatly simplify installation and configuration of complex software.
  • Customizable URL links in the VMware vSphere client and automatic IP allocation.
  • Optimized packaging– you can distribute your packages as a single file and use delta-disk hierarchies to reduce download size.

is quite a lot of stuff to cover in a single blog entry, so I am not
even going to try. Instead, I have included a video showing the
data-driven OVF deployment wizard in action. It shows how a vSphere
user deploys, customizes and gets a complex multi-tiered CRM system up
and running in a few simple clicks and without ever have to interact
with a VM console at all. The CRM system OVF package has been optimized
to take advantage of the new OVF features in vSphere 4.0, including
application-level customization, automatic IP assignments, delta-disk
compression, deployment-time configurations, and vSphere Client URL
integration. In this blog, we will follow up with a series of articles
that describes these features in details and how they can be used in
practice. Fortunately, it turns out that most of them are really
straight-forward to use (and require none to very little guest
modification :).