So I have been doing a lot of work with OVF Tool as of late. In addition, I have been trying hard to ensure that all VMware scripts that I create can be run natively on my Mac (no particular reason). While going through this exercise I ran into some interesting error messages when attempting to deploy OVAs using OVF Tool 3.0.1 on Mac.
I started by attempting to deploy VCSA version 5.1 directly to an ESXi 5.1 host using the following command:
"/Applications/VMware OVF Tool/ovftool" --acceptAllEulas --skipManifestCheck --name=vsm -dm=thin -ds=datastore1 "--net:Network 1=VM Network" --powerOn ~/Downloads/VMware-vCenter-Server-Appliance-18.104.22.16800-947940_OVF10.ova vi://root:firstname.lastname@example.org
This deployment worked as expected. Next, I attempted to deploy VSM version 5.1.2 directly to an ESXi 5.1 host using a similar command:
"/Applications/VMware OVF Tool/ovftool" --acceptAllEulas --skipManifestCheck --name=vsm -dm=thin -ds=datastore1 "--net:VSMgmt=VM Network" --powerOn ~/Downloads/VMware-vShield-Manager-5.1.2-943471.ova vi://root:email@example.com
Opening OVA source: ~/Downloads/VMware-vShield-Manager-5.1.2-943471.ova
The manifest does not validate
Opening VI target: vi://firstname.lastname@example.org:443/
Unexpected exception reading HTTP response body: N7Vmacore3Ssl12SSLExceptionE(SSL Exception: error:260B6084:engine routines:DYNAMIC_LOAD:dso not found)
while parsing serialized value of type string
at line 7, column 4586
while parsing property "eula" of static type ArrayOfString
while parsing serialized DataObject of type vim.vApp.VmConfigSpec
at line 7, column 4213
while parsing property "vAppConfig" of static type VmConfigSpec
while parsing serialized DataObject of type vim.vm.ConfigSpec
at line 7, column 146
while parsing property "configSpec" of static type VirtualMachineConfigSpec
while parsing serialized DataObject of type vim.vm.VmImportSpec
at line 7, column 55
while parsing property "importSpec" of static type ImportSpec
while parsing serialized DataObject of type vim.OvfManager.CreateImportSpecResult
at line 7, column 44
while parsing return value of type vim.OvfManager.CreateImportSpecResult, version vim.version.version8
at line 7, column 0
while parsing SOAP body
at line 6, column 0
while parsing SOAP envelope
at line 2, column 0
while parsing HTTP response for method createImportSpec
on object of type vim.OvfManager
at line 1, column 0
Completed with errors
This deployment failed with a cryptic error message. Initially I thought I might have a bad OVA so I performed a MD5 and confirmed it checked out. Next, I tried to deploy an older version of VSM: version 5.0 – same error message. Was it just VSM? On a whim I attempted to deploy VSM version 5.1.2 to a VCSA instance instead of an ESXi host – same error message. Finally, I attempted to deploy VCSA version 5.1 to a VCSA instance – this deployment failed as well! At this point I realized something funny was going on…
Next, I fired up an Ubuntu 12.04 VM via Fusion. I installed OVF Tool version 3.0.1 for Linux on it and performed that same exact tests. All tests deployed successfully! OK, so it looked like I had proved the issue was with OVF Tool 3.0.1. Next, I decided to revert back to OVF Tool 2.1.0 for Mac.
Note: It appears older versions of OVF Tool are not available for download from vmware.com. Luckily, I had saved the previous version installation package so I could revert back.
I ran the exact tests again this time on OVF Tool version 2.1.0 for Mac and all tests deployed successfully! At this point I had proved there was an issue with OVF Tool 3.0.1 for Mac and that the issue was a regression from OVF Tool 2.1.0 for Mac. I went ahead and submitted the bug to VMware.
© 2013, Steve Flanders. All rights reserved.