Dealing with quite a few different versions of VMware, I get quite a bit of indirect support work. Recently, I had a few issues with an Invalid Manifest File. But when we upgraded OVFTool to resolve that, it also changed the default checksum from sha1 to sha256. This is all fine and dandy for VMware 6.5, but what about 6.0? And anyone using the C# client? If they tried to use it, then the manifest file would fail validation complaining about sha256.  

Thinking back about our previous invalid manifest file problem… VMware 6.5 is compatible with sha1. It just didnt like the extra white spaces the being appended to the end of the file. So, for a greater range of compatibility, lets use the new tool, to write the old checksum format.  

How? First, extract the OVA using either 7zip, or tar depending on what you run.

Next, delete the Manifest File(*.mf), and run OVFTool(4.2.0) as follows:

C:\Program Files\VMware\VMware OVF Tool>ovftool.exe --shaAlgorithm=sha1 -st=OVF -tt=OVA C:\Users\j\Desktop\ova\nginx.ovf C:\Users\j\Desktop\ova\nginx.ova
Opening OVF source: C:\Users\j\Desktop\ova\nginx.ovf
Opening OVA target: C:\Users\j\Desktop\ova\nginx.ova
Writing OVA package: C:\Users\j\Desktop\ova\nginx.ova
Transfer Completed
 - No manifest file found.
 - No manifest entry found for: 'nginx-disk1.vmdk'.
Completed successfully

C:\Program Files\VMware\VMware OVF Tool>


Ignore the no manifest file found warning. I am not really even sure why it cares, since it will regenerate it regardless of whether one exists or not. After the OVA rebuilds, go ahead and extract it. If you now look at the new .mf file, it should be in sha1 rather than sha256. If so, the new OVA can now be loaded into VMware 6.5(without the manifest file problem), and previous versions that only supported sha1.

Overall, even though sha1 isn’t default, this seems like the winning ticket until sha1 is no longer supported in newer versions of VMware.

Related Posts