Home > Applications & Tools, Software Development > VMware ovftool as Development Tool: Good and Bad Parts

VMware ovftool as Development Tool: Good and Bad Parts

October 30th, 2015 Leave a comment Go to comments

If you want to export a virtual appliance for internal deployment, it’s quite easy. The vSphere Web Client or ovftool command line can take care of this easily. But it’s a different story to build a virtual appliance based software product, which should not only make it work, but also include product information.

Here are some information I learned and decisions I made from packaging an OVF product recently. Hope it would be useful for you. You can also check another post on how to compact the virtual disk for smallest OVA or VMDK.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

VMware Studio or OVFTool

Well, if you ask VMware how to create a virtual appliance, it would most likely recommend VMware Studio. I think that should do the work. For me, I just want to have least dependency and least uncertainty, so I chose to do it myself without VMware Studio.

This is essentially a technical trade off. On one side, the VMware Studio does make things easier, but not necessarily simpler. To build a virtual appliance, it needs not only live connection to vSphere, but also quite some manual work. In other words, it makes the process more complicated than it should be. I heard later it got better in CLI and even IDE plug-in. Still, there are some learning curve.

Also, if I remember correctly, the VMware Studio is free of charge, thus it’s purely a cost center. That is why the team started the AppDirector which does bring in revenues. So the future of VMware Studio is not predictable, even though you can argue it’s strategically important.

In general, you want to use tools for automation, but at the same time, you want to evaluate the risk of losing support of the tool. That is why it makes sense to invest a bit more upfront to avoid the risk. That is exactly the rationale behind my decision.

Passing Data via OVF Properties

The guest OS is isolated from VMware infrastructure, but you still want to customize a virtual appliance while deploying it. For that, you can pass in some information from outside VM to the VM guest OS in two different approaches. One is via the OVF environment variables, and the other is via the mounted CD. You would get the same information.

Andreas Peetz has written a great article on how to set up OVF properties and pass on to the virtual machine via VMware Tools. The script there was intended to run on ESXi, therefore cannot be used out of box for Linux guest OSes. But the idea is there, and you can modify the scripts for your Linux OS to programmatically pick up the hostname, ip address, gateway, DNS etc. Different Linux flavors may have slight different command options. The good news is that you control the Guest OS of your virtual appliance. As long you can get it work there, you are done.

In VMware Communities, there is a Shell script to set IP address in SUSE OS which you can reference.

Product Branding

The branding related information can be mostly done with the vSphere Client while connecting to vCenter (not ESXi host directly). From the Edit Setting context menu, we can bring up the Virtual Machine Properties dialog box. On the Options tab, select the vApp Options – Advanced from the left side Setting tree, you can enter Product Name, Version, Full Version, Product URL, Vendor, Vendor URL, etc. All are needed for branding a software product.

For whatever reason, nowhere can you enter end user license agreement (EULA), something you have to accept before moving onto next step during deployment. Luckily, there is an alternative using the ovftool.

Using the ovftool, you can specify the license agreement text file with eula option as follows: (Linux command path would be different but options the same)

"C:\Program Files (x86)\VMware\VMware Player\OVFTool\ovftool" --overwrite --noSSLVerify --compress=9 --eula@=c:\Temp\eula.txt --diskMode=thick  vi://root:vmware@ C:\Users\Steve\Downloads\MyProduct.ova

Notice the @ after the =, it tells the ovftool to read the contect from the license file.

All are good except for automating all the process. You have to enter the product name so on manually on vSphere Client, or with vSphere APIs. But I would rather to have one tool to handle everything for me. I believe you want the same.

It’s not like for the basic information like product name changes frequently, so you can enter the info once at the beginning. But it cannot address one-source-multi-target concern. Basically I want a single VM untouched, but it can create different OVA with slightly different settings – say different language versions of OVAs.

XML Handling Bug

When I used the ovftool with a real license file, I got a strange error saying like this:

Transfer Completed
-	Line 56: Could not parse the document: ‘not well-formed (invalid token)’.
Completed with errors.

I had no clue at first what is the real cause for the error, but based on my experience with XML and OVF format, I kindly guessed it’s related to XML processing. To validate the hypothesis, simply comment out the license file and ran it again. When it succeeded, I know my guess was right. To move on, simply escape the license file using an online tool (many of them). If you have confidential info there, write a script to do the job.

The ovftool export worked well with escaped license file, but the vSphere Client does not de-escape these escaped character, so you will see strange character while deployment. The good news is that most of us don’t read license agreement at all.

My guess is that you can probably get this worked around by changing the exported OVF file directly if you turned off the check sum. Again, I had higher priorities to take care, thus had to move. Should you find a solution, please feel free to leave a comment.

Common OVF Tools (COT)

While studying to solve the problem, I got a nice tool called common ovf tool, which seems to fill the gap of the ovftool nicely. Here is a document for your reading:


With the tool, you can automate everything with command line. And, with one source VM you can create multiple OVA/OVF targets.

As William Lam pointed out, the ovftool is mostly an administrator tool. It can also be used as development/build tool for software product with some limitation. With the help of the COT project, it may fully automate the build of virtual appliance.

  1. No comments yet.
  1. No trackbacks yet.