I recently saw this error and it was while I was trying to deploy an OVA file from a vendor.
This is one I have not seen before - not even a twinge of memory on it. Since this happened during deploy of an OVA I thought I would try expanding the OVA. I use 7-Zip and it was able to extract it without error. This suggests to me that this is not a file type error but a metadata type error.
But no other ideas on what to try. So I checked to see what I could find that might help.
- This one certainly doesn’t. Not even sure why it was suggested.
- Certainly other people are experiencing it, but here is something else that doesn’t help.
- I talk to the OVA vendor and discover that this started out as a Fusion VM, was moved to ESXi and worked fine. Then they produced the OVA.
- This KB article helped - almost. The idea was to convert the VMDK to a the proper format.
- I had extracted the OVA and so now I upload the disk to a datastore.
- Created a VM (it doesn’t start)
- I had found a KB article that I cannot seem to find now for this error. It said to fix this error all that is needed is the following steps:
- Turn off the VM the disk is connected to.
- Disconnect the VMDK from the VM
- SSH to the host and change into the folder where the VMDK is.
- Use the command below to make the disk usable.
- vmkfstools -i old_name.vmdk new_name.vmdk
- Attach the new disk to the VM
- Power VM on and it would start fine.
- In theory, this should be done before the OVA in this particular case. This i snot normal behavior and I don’t know what this was necessary.
You now have a VM running that likely will need to restart once you log into it. Very odd workaround, and odd again to make it work, but it does work. This should not impact many of you.