Edit OVF file and remove all lines below. I'll outline what I'm doing as I think it will help others Ģ. In the meantime, I did a bunch of testing and finally got my process down so that the 100 engineers that utilize my templates don't have to import the template, then edit the vmx file to remove the NVRAM line. I pushed them to create a KB to outline the issue with the resolution as it's clearly a limitation that needs to be addressed. VMware basically told me "this is expected and the only way around it is the workaround of removing the nvram line from the vmx file". After all, isn't this what Virtual Hardware Versions are for? Why is this NVRAM configuration included when Virtual Hardware Version is set to 13 (or less), when this configuration is only compatible with vSphere 6.7 (Virtual Hardware Version 14)? I would like to hear an explanation why this NVRAM configuration is allowed by ovftool 4.3.0 to be exposed to vSphere 6.5 when a known incompatibility exists. the ovf is successfully imported to vSphere 6.5. After making the following changes to the. Neither error message suggests the underlying cause of the issue, which is an incompatibility with NVRAM-containing. vSphere 6.5 Tasks View: The task was cancelled by a user.
#Ovf vmware not working code
ovftool: Bad response code (500) from POST request.We observed similar behaviour using ovftool 4.3.0 which even boasts of improved support for vSphere 6.7 and NVRAM. I consider this a bug which VMware should be accountable for.