OVF Tool : Failed to load OpenSSL libraries

[ekbanks]

I ran the OVF Tool at the command line as sudo

I ran the OVF Tool at the command line as sudo because I running it as myself would bomb when trying to open .vmx file.

I have run in sudo in both the OVF Tool complete download and OVF Tool via Fusion.

Fusion 7.1.1

#sudo ./ovftool --acceptAllEulas /users.....

I received the following error. Any assistance is appreciated.

I see the crypto.1.0.1.dylib in the director. Permissions look good.

SSLLoadSharedLibraries: Failed to load OpenSSL libraries. libdir is /Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/lib

VMware Fusion Error:

Unable to open the '/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/libcrypto.1.0.1.dylib' file for read access: Could not find the file.

VMware Fusion unrecoverable error: (vthread-4)

SSLLoadSharedLibraries: Failed to load OpenSSL libraries. libdir is /Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/lib

A log file is available in "/var/root/Library/Logs/VMware/vmware-ovftool-975.log".

You can request support.

To collect data to submit to VMware support, choose "Collect Support Information" from the "Help" menu.

You can also run "VMware Fusion Problem Reporter.tool" inside the VMware Fusion application bundle directly.

We will respond on the basis of your support entitlement.

[SeanLuce]

This seems to be an issue with the OVF Tool that is included with VMware Fusion.  I get the same error.

However, there is a stand alone version of the OVF Tool for OS X here: https://my.vmware.com/web/vmware/details?productId=352&downloadGroup=OVFTOOL350

This version will be in \Applications\VMware OVF Tool" and it works great.

Good luck!

[ekbanks]

Thank you for the response but I am getting the same exact error which I find fascinating... To get the same exact error with two different tools.

[ekbanks · Accepted solution]

Issue resolved... I did not have the full path.

I posted the resolution on VMware Fusion 7.1.1 OVF Tool Error + Drag & Drop | common denial

because the resolution was to drop and drop the file and folder and you won't run into my issue again.

Also... no need to run as sudo

[silverstr8p]

duplicated all the steps in your howto, still got the same error:

SSLLoadSharedLibraries: Failed to load OpenSSL libraries. libdir is /Applications/VMware OVF Tool/lib

VMware Fusion Error:

Unable to open the '/Applications/VMware OVF Tool/ovftool/libcrypto.1.0.1.dylib' file for read access: Error.

Tried copying libs into tool root directory, still same failure. Ran as root and sudo. Is there an updated tool I can find somewhere that solves the path issue? I am thinking about using the 4.0 tool, but don't want to cause conflicts.

[silverstr8p]

I think I figured it out, the tool only supports Mac OSX 10.7 and 10.8, I'm using 10.10.5 Yosemite 😕

Anyone know of a workaround on Yosemite?

[Stevan_White]

I got this working in Linux anyway.  Here are my notes.

Downloaded from vmware

VMware vSphere Virtual Disk Development Kit 6.5.2

(VDDK)

VMware-vix-disklib-6.5.2-6195444.x86_64.tar.gz

This required getting an account with them.

================================================================

$ ./vmware-vdiskmanager -e path_to_orig.vhd

Disk chain is consistent.

(This is the sign that something has run afoul.)

================================================================

Trying to run vmware-vdiskmanager with other options gives error:

SSLLoadSharedLibraries: Failed to load OpenSSL libraries. libdir is /usr/lib/vmware

http://pubs.vmware.com/vsphere-5-5/index.jsp?topic=%2Fcom.vmware.vddk.pg.doc%2FvddkInstall.4.3.html

gives advice to edit the  LD_LIBRARY_PATH, which isn't helpful.

My guess is the path is hard-wired.

The 64-bit .so libraries must be exactly in /usr/lib/vmware.

A soft link is insufficient!

The lib64/ directory must be renamed

        /usr/lib/vmware.

================================================================

Trying to repair using the -R option seems to do nothing.

================================================================

Trick is to *convert* the virtual disk, rather than repair it.

$ ./vmware-vdiskmanager -r path_to_orig.vhd -s 40GB -t 0 path_to_modified.vhd

The modified virtual hard disk now boots in VirtualBox.