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-5.1.0.5300-947940_OVF10.ova vi://root:[email protected]
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 protected] Opening OVA source: ~/Downloads/VMware-vShield-Manager-5.1.2-943471.ova The manifest does not validate Opening VI target: vi://[email protected]:443/ Error: 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.
