Home > Virtualization > Deploying OVA onto VMware vSphere: Issues and Workarounds

Deploying OVA onto VMware vSphere: Issues and Workarounds

March 31st, 2017 Leave a comment Go to comments

Update: this issues are fixed with the VM Deployer tool we just release as described here.

With the increasing adoption of VMware WebClient, we got more support cases from customers who use it for deploying our search engine appliance. In one sentence, it does NOT work and you will get error messages like, “the provided manifest file is invalid OVF.”

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


Although it’s an issue caused by VMware, we have to deal with the issue and tell customers how to work around it. I think the issue goes beyond our OVA, but all the other OVA based appliances from all vendors including those from VMware. So the workarounds we suggested to our customers will also benefit you.

Let’s first take a look at the workarounds. We’ll touch the causes behind the scene along the way.

Standalone vSphere Client

Although VMware claims it’s not longer supported and no new features to be added in this well designed GUI, it’s still the fastest and most reliable GUI from VMware. Simply because it’s based on Microsoft C# and it’s standalone, it’s labelled as legacy, and out of favor by VMware. As I know, most customers still love it – not because we like Windows but because it’s the one that works best. Well, there could be many debates why VMware should or shouldn’t make the decision, but that belongs to its own post. I have actually touch on that before with this post (Too Early to Say Goodbye to vSphere Client)

As we care here, the standalone vSphere Client works well with deploying OVA or OVF.

OVFTOOL Command Line

The Ovftool has different versions on different platforms. You can find the document on how to use it. The command line can not only deploy OVA for you, but also export a VM, to/from either vCenter or ESXi. Very powerful indeed. If you find slow exporting, please read this post.(http://www.doublecloud.org/2016/11/slow-exporting-ovfova-from-vsphere-client-or-ovftool-a-quick-tip-can-save-you-hours/)

For the first time users, it may be a little challenging given the many different options, especially required data formats. Once you have a sample to start with, it’s actually very easy. If your setting is slightly different from deploying our search appliance, you can always refer to the user guide or simply check the command help.

ovftool --acceptAllEulas -ds="datastore1” -dm="thin" --net:"VM Network"="VM Network" /Users/steve/Downloads/DoubleCloudVSearchV33.ova vi://root:doublecloud@

Update: thanks to Edward Haletky (@Texiwill), who introduced me to a new tool he had created as part of acclib on top of the ovftool and govc. As you may wonder why another command is needed? Here is why from the Website.

2 scripts to use govc or ovftool to import a directory full of ova and ovf files. The ovftool will automatically unpack .zip files containing OVFs and its files as well as take a single OVA/OVF as an argument.

So if you have multiple OVA/OVFs in directory, it will do it all in one line for you. Isn’t that awesome?! You can find more about the tool here.

WebClient with Decompressed Data

To understand why the OVA doesn’t work as it is, you need a little background. The OVA is essentially a renamed format of Unix tar format. The standalone vSphere Client can take OVA and decompress it on the fly easily because it’s a local application. The WebClient cannot due to security limitation of browser.

With this in mind, you can use a local application, like 7Zip, to uncompress the OVA to an OVF and vmdk files. Then, you can pick the OVF to deploy.

WebClient with Client Integration Plugin

The WebClient cannot decompress OVA due to security restriction, but this can be worked around by the Client Integration Plugin which is granted as local permissions.

In my opinion, the whole Client Integration Plugin story actually defeats the initial intention of WebClient which is to make the application portable, because it first depends particular platform and also ground the full feature to a particular machine. Once it’s there, there is actually no longer portable. Although slightly better than standalone one in Linux and MacOS support, but not really a big deal. VMware can always afford to give Mac users a free Fusion license.

Having these workarounds in place, it’s not too big deal of deploying OVA, especially after you read this post. But really the VMware team has to think more end to end from users’ perspectives, and really make these common use cases simple and convenient. While the old mess are still there, efforts like HTML Client may create more with all the good intentions and ambitions. I hope I don’t have to write yet another post for the new HTML5 Client. To be accurate, the HTML5 Client is officially called vSphere Client.

Categories: Virtualization Tags: , , ,
  1. March 31st, 2017 at 18:32 | #1

    [DoubleCloud] Deploying OVA onto VMware vSphere: Issues and Workarounds https://t.co/XxwXDbG1Cw

  2. Anil
    January 16th, 2018 at 19:26 | #2

    I am trying to run the following ovftool command: ovftool –skipManifestCheck -dm=thin -ds={ds name} –net:”{}”=”{} http:{Remote location where OVA file is located} “vi://{username}:{password}@{PublicIP of host}”.
    And I am getting the following error:
    Opening OVA source: “http:{Remote location where OVA file is located}”
    Error: Internal error: Failed to connect to server
    Completed with errors

    Please provide needful information.

  3. February 18th, 2018 at 15:45 | #3

    Hi Anil, as the error message suggested, the remote server serving your OVA may not be connectable. Can you ping the host? -Steve

  1. No trackbacks yet.