SHA digest error when importing ova with VMWare Workstation 16

[ioctl2]

Describe the issue you are experiencing

Importing the Home Assistant OS ova appliance into VMWare Workstation version 16.2.4 build-20089737 fails with this error:
SHA digest of file home-assistant.vmdk does not match manifest.

This happens with the following versions of HAOS (note that this includes a recent dev version):

haos_ova-8.4.ova
haos_ova-10.0.dev20220907.ova
haos_ova-8.5.ova

If I remove the manifest home-assistant.mf from the .ova, the appliance imports successfully. Also noteworthy is that the appliance imports into Oracle VirtualBox (6.1) and VMWare ESXi (6.7, 7.1) as-is, without error.

The actual checksums are fine. As an example, the haos_ova-8.5 manifest (home-assistant.mf) contains these lines:

SHA256(home-assistant.ovf)= 64504b3ae7dd5bf32d74187874538bcf2ea204e1ce0cfbbee399e00ed46d4982
SHA256(home-assistant.vmdk)= 12cec555efcb96a675b7b4aab283ae0148f2b8f36a6983c3908b94519b9b7b12

When I compute the checksums for the two referenced files, they match:

home-assistant.ovf SHA-256: 64504b3ae7dd5bf32d74187874538bcf2ea204e1ce0cfbbee399e00ed46d4982
home-assistant.vmdk SHA-256: 12cec555efcb96a675b7b4aab283ae0148f2b8f36a6983c3908b94519b9b7b12

I have searched existing issues to avoid posting a dup, and found some related discussion, but nothing that addresses this specific issue with VMWare Workstation. One such issue was #826 - since fixed/closed - dealing with ESXi import errors, but one commenter reported that this was not yet fixed in relation to Workstation (see #826 (comment) and #826 (comment))

Many appliances still use SHA1 for the manifest file, and it made me wonder if perhaps VMWare Workstation only supported that, and not SHA256. There was an issue related to ESXi and the hash function on the nextcloud issue tracker nextcloud/vm#910 (comment) but this was dealing with ESXi and not Workstation, and with an older (5.5) unsupported (https://kb.vmware.com/s/article/51491) release of the hypervisor.
I looked at the manifest of another project (https://gns3.com/software/download-vm) that ships OVA appliance files, and it uses SHA256 hashes, and the OVA imports into Workstation fine, so the same should apply to the HAOS one. Interestingly, they ship a separate OVA files for Workstation/Fusion and ESXi.

[this is my first bug report for this project, so I'd appreciate any pointers if anything is amiss in my report]

What operating system image do you use?

ova (for Virtual Machines)

What version of Home Assistant Operating System is installed?

NA

Did you upgrade the Operating System.

No

Steps to reproduce the issue

1. Download OVA appliance.
2. Start to import into VMWare Workstation.

Anything in the Supervisor logs that might be useful for us?

N/A

Anything in the Host logs that might be useful for us?

N/A

System Health information

No response

Additional information

No response

[agners]

I remember last time I looked at it that the person mentioned that Workstation didn't work, but since it wasn't a problem for him I did not further investigate (maybe that also was an old VMware Workstation version).

However, the fact that even the latest VMWare Workstation doesn't work is not nice.

Many appliances still use SHA1 for the manifest file, and it made me wonder if perhaps VMWare Workstation only supported that, and not SHA256.

That is what I assumed first, and if that would be the case I'd almost say let's push VMware to finally support a modern hash algorithm 😄

I looked at the manifest of another project (https://gns3.com/software/download-vm) that ships OVA appliance files, and it uses SHA256 hashes, and the OVA imports into Workstation fine, so the same should apply to the HAOS one. Interestingly, they ship a separate OVA files for Workstation/Fusion and ESXi.

That is an interesting find! I downloaded the file, and indeed it seems to use SHA256 sums, and even in the very same format as Home Assistant OS:

SHA256(GNS3 VM.ovf)= 195c52c7ebba790bca27b57ba578f459dde16e0922c22f1a70ab7001a50563e5
SHA256(GNS3_VM-disk1.vmdk)= 7b064e18d64105f8f7ad3fcec642436344149e2894886ae8e471958b6637f680
SHA256(GNS3_VM-disk2.vmdk)= fa1b56566b1585a948c6769b2ba93a9b7b12315584b8f645ed824d087933d3ab

SHA256(home-assistant.ovf)= 64504b3ae7dd5bf32d74187874538bcf2ea204e1ce0cfbbee399e00ed46d4982
SHA256(home-assistant.vmdk)= f570066d72d4974e93d408a90ee99bb386850d3d06abdf71ac452168833596fb

I also checked file endings, the both seem to be UNIX style.

Just to be clear, you are saying that GNS3 VM.ova (sha256 hash d4b15a691c132522d1c88aa62487c0702826addee15b1be32e5f610fc1b6afab, extracted from GNS3.VM.VMware.Workstation.2.2.34.zip) imports fine with VMware Workstation while HAOS doesn't? Do you import it as zip file or ova (does it make a difference)?

One thing I notice is that in our case the ova file name is different (e.g. haos_ova-9.0.rc2.ova/home-assistant.mf to the containing mf file name, while they use the same (GNS3 VM.ova/GNS3 VM.mf). Seems weird to that this would matter.

[ioctl2]

I remember last time I looked at it that the person mentioned that Workstation didn't work, but since it wasn't a problem for him I did not further investigate (maybe that also was an old VMware Workstation version).

However, the fact that even the latest VMWare Workstation doesn't work is not nice.

Yep, but in my case I use Workstation and ESXi extensively, so a fix would ease my workflow. The workaround isn't lengthy or complicated, but it adds up.

Many appliances still use SHA1 for the manifest file, and it made me wonder if perhaps VMWare Workstation only supported that, and not SHA256.

That is what I assumed first, and if that would be the case I'd almost say let's push VMware to finally support a modern hash algorithm 😄

VMWare products sometimes have very anachronistic components, so it was a short lived "aha" moment for me when I thought SHA256 was too "new" for Workstation.
One thing I noticed is that some OVA publishers also include a certificate to make it a signed appliance. I'm not sure if this is something you'd want to look into, but while researching the import issue, I saw some mentions (sadly I didn't save the link) that the hash manifest was in the OVA for security, but it really isn't, and can only be relied upon to verify the integrity of the downloaded file. Integrity, but not authenticity. For the latter, it would need to be signed. I imagine that the popularity of SHA1 manifests shipped with unsigned appliances - as opposed to SHA256 - is to provide better compatibility with older hypervisors while still allowing integrity verification, and security is not the goal.

Here are some other examples of appliances currently shipped with a SHA1 digests in their manifests: VMWAre Photon OS (but they ship a cert within the ova!), turnkey linux appliances, blackarch linux, Bitnami (absorbed by VMWare) appliances, nixos. Whonix uses SHA1 hashes within their OVA too, but they provide external SHA512 digests and sign the container with GPG.

I am not advocating for one way over another, but I thought the above would be helpful to the discussion.

I looked at the manifest of another project (https://gns3.com/software/download-vm) that ships OVA appliance files, and it uses SHA256 hashes, and the OVA imports into Workstation fine, so the same should apply to the HAOS one. Interestingly, they ship a separate OVA files for Workstation/Fusion and ESXi.

That is an interesting find! I downloaded the file, and indeed it seems to use SHA256 sums, and even in the very same format as Home Assistant OS:

SHA256(GNS3 VM.ovf)= 195c52c7ebba790bca27b57ba578f459dde16e0922c22f1a70ab7001a50563e5
SHA256(GNS3_VM-disk1.vmdk)= 7b064e18d64105f8f7ad3fcec642436344149e2894886ae8e471958b6637f680
SHA256(GNS3_VM-disk2.vmdk)= fa1b56566b1585a948c6769b2ba93a9b7b12315584b8f645ed824d087933d3ab

SHA256(home-assistant.ovf)= 64504b3ae7dd5bf32d74187874538bcf2ea204e1ce0cfbbee399e00ed46d4982
SHA256(home-assistant.vmdk)= f570066d72d4974e93d408a90ee99bb386850d3d06abdf71ac452168833596fb

I also checked file endings, the both seem to be UNIX style.

Just to be clear, you are saying that GNS3 VM.ova (sha256 hash d4b15a691c132522d1c88aa62487c0702826addee15b1be32e5f610fc1b6afab, extracted from GNS3.VM.VMware.Workstation.2.2.34.zip) imports fine with VMware Workstation while HAOS doesn't? Do you import it as zip file or ova (does it make a difference)?

I just tried it again for a sanity check. Can confirm, GNS3 VM.ova found within GNS3.VM.VMware.Workstation.2.2.34.zip imports fine.
A .zip cannot be directly imported into Workstation: "GNS3.VM.VMware.Workstation.2.2.34.zip" is not a virtual machine configuration file (.vmx).

One thing I notice is that in our case the ova file name is different (e.g. haos_ova-9.0.rc2.ova/home-assistant.mf to the containing mf file name, while they use the same (GNS3 VM.ova/GNS3 VM.mf). Seems weird to that this would matter.

Extracting the OVA and importing the OVF within it also does not work, and results in the same error. This, again, can be bypassed by removing the manifest file. (The files within the HAOS OVA are: home-assistant.mf, home-assistant.ovf, home-assistant.vmdk)

I tried to convert the HAOS 8.5 OVA using VMWare's ovftool (download) to OVF (like described here), in hope that it would provide a more verbose and helpful output. The process failed, but the output is somewhat more verbose:

C:\opt\_cli\ovftool\VMware-ovftool-4.4.3-18663434-win.x86_64>ovftool.exe "c:\tmp\2\haos_ova-8.5.ova" "c:\tmp\2\test.ovf"
Opening OVA source: c:\tmp\2\haos_ova-8.5.ova
Warning:
 - Line -1: Unsupported value 'cpuid.coresPerSocket' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'svga.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.speed' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.deviceType' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.port' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.parent' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'ctkEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'sata0:0.ctkEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.deviceType' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.port' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.parent' for attribute 'key' on element 'ExtraConfig'.
Opening OVF target: c:\tmp\2\test.ovf
Writing OVF package: c:\tmp\2\test.ovf
Transfer Completed
The manifest validates
Error: SHA digest of file home-assistant.vmdk does not match manifest
Warning:
 - No supported manifest(sha1, sha256, sha512) entry found for: 'home-assistant.vmdk'.
Completed with errors

I then extracted the same OVA file and attempted to use ovftool to re-create the OVA from the loose trio (cmdk, mf, ovf). This is where things got interesting, and I think may be pointing at the actual problem:

C:\opt\_cli\ovftool\VMware-ovftool-4.4.3-18663434-win.x86_64>ovftool.exe "C:\tmp\2\haos_ova-8.5\home-assistant.ovf" "C:\tmp\2\haos_ova-8.5\home-assistant.ova"
Opening OVF source: C:\tmp\2\haos_ova-8.5\home-assistant.ovf
The manifest validates
Warning:
 - Line -1: Unsupported value 'cpuid.coresPerSocket' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'svga.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.speed' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.deviceType' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.port' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.parent' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'ctkEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'sata0:0.ctkEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.deviceType' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.port' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.parent' for attribute 'key' on element 'ExtraConfig'.
Opening OVA target: C:\tmp\2\haos_ova-8.5\home-assistant.ova
Writing OVA package: C:\tmp\2\haos_ova-8.5\home-assistant.ova
Transfer Failed
Error: SHA digest of file home-assistant.vmdk does not match manifest
Warning:
 - Wrong file size specified in OVF descriptor for 'home-assistant.vmdk' (specified: -1, actual 518352384).
Completed with errors

I believe that this is the relevant section from the ovf:

  <DiskSection>
    <Info>List of the virtual disks used in the package</Info>
    <Disk ovf:capacity="34359738368" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:boot="True" vbox:uuid="5f042839-c478-43d9-9eb0-fd8a902146ec"/>
  </DiskSection>

I looked at this section in ovf files from other appliances, and it does look quite different.

GNS3 (from GNS3.VM.VMware.Workstation.2.2.34, GNS3 VM.ovf):

  <References>
    <File ovf:href="GNS3_VM-disk1.vmdk" ovf:id="file1" ovf:size="1654575104"/>
    <File ovf:href="GNS3_VM-disk2.vmdk" ovf:id="file2" ovf:size="1954304"/>
  </References>
  <DiskSection>
    <Info>Virtual disk information</Info>
    <Disk ovf:capacity="20000" ovf:capacityAllocationUnits="byte * 2^20" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="3783327744"/>
    <Disk ovf:capacity="500000" ovf:capacityAllocationUnits="byte * 2^20" ovf:diskId="vmdisk2" ovf:fileRef="file2" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="27197440"/>
  </DiskSection>

Bitnami postgres (bitnami-postgresql-14.5.0-5-r05-linux-vm-debian-11-x86_64-nami.ovf from bitnami-postgresql-14.5.0-5-r05-linux-vm-debian-11-x86_64-nami.ova):

  <References>
    <File ovf:href="bitnami-postgresql-14.5.0-5-r05-linux-vm-debian-11-x86_64-nami-disk1.vmdk" ovf:id="file1" ovf:size="559452160"/>
  </References>
  <DiskSection>
    <Info>Virtual disk information</Info>
    <Disk ovf:capacity="16000000000" ovf:capacityAllocationUnits="byte" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="1551826944"/>
  </DiskSection>

So I thought that it would be interesting to see what a section that VMWare Workstation is happy with looks like.
To get an ovf that Workstation is happy with, I tried the following:

1. removed the HAOS 8.5 manifest file from an extracted haos_ova-8.5.ova, and imported it into Workstation ("the workaround"). This step was successful, and the new VM showed up in my Workstation list. I did not try to power it on as I was only interested in extracting a working DiskSection stanza.
2. I exported the VM from Workstation to ovf (this feature is built into Workstation).
   The DiskSection of the resulting ovf looked like this:

  <References>
    <File ovf:href="haos85-disk1.vmdk" ovf:id="file1" ovf:size="537410048"/>
  </References>
  <DiskSection>
    <Info>Virtual disk information</Info>
    <Disk ovf:capacity="32" ovf:capacityAllocationUnits="byte * 2^30" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="1107755008"/>
  </DiskSection>

3. I then used ovftool to convert the ovf to ova (please excuse the messy directory naming, this was a quickie):

C:\opt\_cli\ovftool\VMware-ovftool-4.4.3-18663434-win.x86_64>ovftool.exe "C:\tmp\2\fixed3\haos85.ovf" "C:\tmp\2\fixed3\haos85.ova"
Opening OVF source: C:\tmp\2\fixed3\haos85.ovf
The manifest validates
Warning:
 - Line -1: Unsupported value 'cpuid.coresPerSocket' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'ctkEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge0.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge4.functions' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge4.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge4.virtualDev' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge5.functions' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge5.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge5.virtualDev' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge6.functions' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge6.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge6.virtualDev' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge7.functions' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge7.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'pciBridge7.virtualDev' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'sata0:0.ctkEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'svga.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.deviceType' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.parent' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.port' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:0.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.deviceType' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.parent' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.port' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'usb:1.speed' for attribute 'key' on element 'ExtraConfig'.
Opening OVA target: C:\tmp\2\fixed3\haos85.ova
Writing OVA package: C:\tmp\2\fixed3\haos85.ova
Transfer Completed
Completed successfully

Both the resulting ova and the ovf import into Workstation fine.
They also import into VirtualBox (Version 6.1.36 r152435 (Qt5.6.2)). However, it looks like the import/export through Workstation broke/reset VirtualBox specific default settings such as guest OS ("Other Linux (64-bit)" -> "Other/Unknown (64-bit)"), audio controller (Intel HD Audio -> ICH AC97), disk controller type (only got renamed in the vbox UI it seems, went LSILogic -> SCSI), network controller type (paravirtualized -> Intel PRO 1000 MT Server), EFI (it reverted to legacy), vRAM allocation (16M -> 4M), and maybe others).
I searched for vbox:Machine in the exported ova/ovf and it's missing in both, so the above observation makes sense.

Writing ovf descriptors is not my forte, so I hope the findings I shared will help you find the problem, and this is all I can offer for now.

Side notes:

• VMWare Player is free for non-commercial use as per their FAQ and is capable of importing appliances. If the license terms are compatible with your situation, it might be a good way for you to test HA appliances, assuming you do not already own a copy of Workstation.
• This post on vmware communities seems somewhat relevant, but I don't think if it is of much help. It deals with digest file formatting woes (a VMWare employee responded but did not help the OP).
• The guest OS defined in the ovf of the appliance will have an effect on what features are available. Same goes for VM hardware version. This is a topic for another issue, but if the appliance is getting reworked anyway, it's worth remembering.
• I have a feeling that a one size fits all for the ova might be an elusive endeavour. Again, not too versed in this, so maybe there is a common denominator. But some appliances are shipped with separate ovas for different hypervisors, and perhaps it is an option here, if a solution turns out to be too ugly or unworkable otherwise.

Sorry for the messy formatting. I noticed half way through but I think it is readable enough.

[agners]

Hm, I see that we do not have ovf:size in the file reference section defined, this error suggests this could be the problem:

Error: SHA digest of file home-assistant.vmdk does not match manifest
Warning:
 - Wrong file size specified in OVF descriptor for 'home-assistant.vmdk' (specified: -1, actual 518352384).

Although it is optional according to spec...

<xs:attribute name="size" type="xs:unsignedLong" use="optional">
  <xs:annotation>
    <xs:documentation>
      Size in bytes of the files (if known)
    </xs:documentation>
  </xs:annotation>
</xs:attribute>

Can you try adding ovf:size="518352384" to the ovf file and see if that imports properly?

[ioctl2]

I gave it a go, but no dice. Workstation still complains about the digest.
ovftool no longer complains about the file size not being specified, but it too refuses to work with the ovf:

Transfer Failed
Error: SHA digest of file home-assistant.vmdk does not match manifest
Completed with errors

This is what I changed the relevant section to:

  <References>
    <File ovf:id="file1" ovf:href="home-assistant.vmdk" ovf:size="518352384"/>
  </References>
  <DiskSection>
    <Info>List of the virtual disks used in the package</Info>
    <Disk ovf:capacity="34359738368" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:boot="True" vbox:uuid="5f042839-c478-43d9-9eb0-fd8a902146ec"/>
  </DiskSection>

[agners]

When ovf:Machine section is removed the home-assistant.ovf successfully validates against dsp8023_1.0.xsd, so the XML should by semantically correct and complete. The SHA256 hashes are clearly correct too. I don't see why this is a HAOS issue, this seems to be a VMware Workstation issue to me. Can you open a bug with the VMware folks?

[ioctl2]

Sorry, I am not ready to chase VMWare. I think this should be a task for someone from the HA team, if they/you want ova imports to work. But if not, then I would suggest to update the documentation to say that the ova method for Workstation isn't supported.

[agners]

Sorry, I am not ready to chase VMWare.

Same here 😅

But if not, then I would suggest to update the documentation to say that the ova method for Workstation isn't supported.

Works for me.

[agners]

Seems there is no way to open a bug report without support agreement. Also, it seems there has been made an attempt int he past (at least this community forum thread looks very similar).

[ioctl2]

Whether we've hit a VMWare bug or not, other appliance vendors somehow manage to offer combined ova files that work with VirtualBox, ESXi and Workstation. So this should be possible.

I just tried to import the Bitnami Consul ova into my VirtualBox, Workstation, and ESXi instances, and it imports fine in all three. Perhaps the HAOS template can be crafted in a similar way? The appliance is pretty small - perhaps you could take a look at how they do it.

There is also the option of creating a separate appliance.

Finally, as far as I know, ovftool is available for Linux, and is scriptable. It should be able to generate ovf/ova from a vmx. Not sure what the license terms are.

What do you think?

[jens-maus]

Have you guys tried to import the ova images we at the RaspberryMatic project generate in a similar manner than here? See https://github.com/jens-maus/RaspberryMatic/releases/latest

[ioctl2]

Have you guys tried to import the ova images we at the RaspberryMatic project generate in a similar manner than here? See https://github.com/jens-maus/RaspberryMatic/releases/latest

Thank you for jumping in! Also, awesome project!
I just tried to import RaspberryMatic-3.65.8.20220831.ova, but sadly:
SHA digest of file RaspberryMatic.vmdk does not match manifest.

Which version of Workstation did your team test the ova on? I wonder if this is a breaking change introduced in a recent Workstation build.

[ioctl2]

Looks like the latest HAOS 9 ova fails to import on Workstation 15.0.3 build-12422535.

[ioctl2]

Here is a relevant Twitter exchange that I think is worth pursuing.

[0x4d4e]

I ran into the same issue when generating a Kali-Linux VM Image using https://gitlab.com/kalilinux/build-scripts/kali-vm.

As per the feedback on the Twitter exchange, using a streamOptimized VMDK image seems to cause the issue. Removing -o streamOptimized when building the .ova (see https://gitlab.com/kalilinux/build-scripts/kali-vm/-/blob/main/scripts/export-ova.sh) results in a larger image, but it can be imported without issues in VMware Workstation afterwards. Seems this issue has to be fixed by VMware ...

You can also convert an existing streamOptimized vmdk image in an ova (after extracting the tar archive) using qemu-img:

qemu-img convert -O vmdk input.streamOptimized.vmdk output.vmdk    # no -o streamOptimized

After replacing the original vmdk (using the original name or updating the reverence in the .ovf file) and updating the hash in the manifest file, the .ovf file is imported successfully. See also https://gitlab.com/kalilinux/build-scripts/kali-vm/-/blob/main/scripts/export-ovf.sh for generating the un-streamOptimized output in the .ovf build tool of kali-vm (https://gitlab.com/kalilinux/build-scripts/kali-vm/-/blob/main/scripts/export-ovf.sh).

[agners]

@0x4d4e interesting finds, thanks for sharing!

From what I understand the streamOptimized option allows sparse files (from at least judging by this documentation).

For HAOS, the image size increases from 436MB to 923MB (streamOptimized to monolithicSparse).

For the pure vmdk file currently monolithicSparse is used, but there we use zip compression afterwards. Maybe we can use that as well for ovf.

It seems that ovf supports gzip compressed disks, so maybe that is an option. However, it seems that some (other) VMware products have problem with that (or here) 😰 So not sure if that would be a good option for VMware users.

As per the feedback on the Twitter exchange

Do you happen to have a link to that thread?

[0x4d4e]

Do you happen to have a link to that thread?

From @ioctl2 's comment above mine: https://twitter.com/mikeroySoft/status/1570161059172077569

[github-actions]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ioctl2]

This is still an issue.

[pinksocks]

This is still an issue.

He is correct.
Anyone still having the issue, try these instructions:
https://rootedshell.medium.com/failed-to-open-virtual-machine-sha1-digest-of-file-xxxxxxxx779-disk1-vmdk-does-not-match-manifest-7d0d94db4451

STEP 1: Extract the xxxxxxxx.ova file with 7zip.
STEP 2: Delete [xxxxx.mf] manifest file.
STEP 3: Open xxxxxxxxxxxx.ovf File in VMWare.
STEP 4: Virtual Machine Import, Done. 👍

[agners]

Yes, this is still a problem, but it is a bug in VMWare Workstation 16. Unfortunately, I was unable to report the bug because I am not a VMware customer. If you have a support agreement with VMWare, please report the issue with VMware.

See #2121 (comment).

[elboulangero]

I did more research on that one, at https://gitlab.com/kalilinux/build-scripts/kali-vm/-/issues/25#note_1290346720. From what I can see, the issue is not in the .ovf, it's in the .vmdk. If it's created with vmware tools (eg. vmware-vdiskmanager) it imports fine, but if it's created with qemu-img for example, it fails with the « SHA checksum does not match manifest » error.

So definitely a bug in VMware, even more after reading the twitter message from @mikeroySoft that was mentioned above. If vmware do the checksum after converting the disk back and forth, no surprise the checksums don't match... But it might match (by chance) if the disk is decompressed/recompressed using the exact same algorithm and it's deterministic, ie. the disk was created using vmware own tools.