Cannot Import OVF file from vCenter 6.7 to 6.5

[Mork8855]

Hello,

Im trying to export VM from vcenter appliance 6.7 to vcenter applicence 6.5

the export action create 4 types of files: NVRAM, OVF, VMDK, MF.

Once im trying to import the VM on the Vcenter 6.5 i get this Error: "Deployed an OVF with NVRAM is not suportted (incompatible vCenter version).

Somebody know how to reslove this issue?? thanks.

[a_p_ · Accepted solution]

What you can try is to remove any references to the .nvram file from the .ovf file to see whether this will work.

Note that in case of modifying any of the files, you may need to delete (or rename) the .mf file due to the changed signature.

André

[Mork8855]

Hi a.p,

Thanks for your advise.

I'd try it but it's right to me after i get to the final phase of the deploy OVF wizard, this meesage:

"The checksum(s) from the provided manifest file do not match the content of file(s): RailWays-SM-BI.ovf.

RailWays-SM-BI.ovf. - the name of the VM.

I'd changed the .mf file - delete the nvram pointer row AND the .ovf file - the same all the rows that mentions the .nvram rows.

you have any idie?

thanks.

[a_p_]

Unless I'm missing something that may have changed, it's only the manifest (.mf) file which has the checksum information.

Can you please delete the .mf file, and try the import again?

André

[Mork8855]

YES!! Now its working, thanks you very much!

[ethandlowry]

To note, while this works, I don't think this is a "resolution" as it's basically a work around due to 6.7 now exporting NVRAM files, and previous versions of vSphere not supporting importation of those NVRAM files. This causes issues powering on any Template/VM exported from 6.7 and being imported into any pre 6.7 environment.

I have a case open about this and am attempting to get VMware to understand the issue and will update this thread if I get more details.

[ethandlowry]

Per VMware - "I discussed this with my escalation team and the conclusion is that if you are exporting the vm from 6.7 you could only deploy it to 6.7 because of nvram feature, if you need to deploy the template to pre 6.7 you could use the workaround."

So basically, to export a VM from 6.7 and import it into pre 6.7 you must remove the nvram line from the vmx file to make it work.

I have pushed VMware to create a KB about this as it's a pretty big change that has been introduced without being noted anywhere. We'll see if a KB is created.

[brianstock]

I consider this a bug which VMware should be accountable for. We observed similar behaviour using ovftool 4.3.0 which even boasts of improved support for vSphere 6.7 and NVRAM. The following symptoms were observed:

• ovftool: Bad response code (500) from POST request
• vSphere 6.5 Tasks View: The task was cancelled by a user.

Neither error message suggests the underlying cause of the issue, which is an incompatibility with NVRAM-containing .ovf templates. After making the following changes to the .ovf template:

-    <File ovf:href="image-name-file1.nvram" ovf:id="file2" ovf:size="8684"/>

...

-      <vmw:ExtraConfig ovf:required="false" vmw:key="nvram" vmw:value="ovf:/file/file2"/>

+      <vmw:ExtraConfig ovf:required="false" vmw:key="nvram" vmw:value="image-name.nvram"/>

+      <vmw:ExtraConfig ovf:required="false" vmw:key="virtualhw.productcompatibility" vmw:value="hosted"/>

... the ovf is successfully imported to vSphere 6.5.

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. 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)?

[ethandlowry]

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". 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. 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'll outline what I'm doing as I think it will help others;

1. Export the VM from 6.7 as normal.

2. Edit OVF file and remove all lines below. These are all features new to 6.7 that are not compatible with previous vSphere versions. The only one that causes the issue this thread is about are the two nvram lines, but to make it clean I've removed the other 3 lines as well (this prevents the warning that there are features in the VM being imported that aren't recognized/supported when you import into previous versions).

• <File ovf:id="file3" ovf:href="<VM Name>.nvram" ovf:size="8684"/>
• <vmw:Config ovf:required="false" vmw:key="flags.vbsEnabled" vmw:value="false"/>
• <vmw:Config ovf:required="false" vmw:key="flags.vvtdEnabled" vmw:value="false"/>
• <vmw:Config ovf:required="false" vmw:key="bootOptions.efiSecureBootEnabled" vmw:value="false"/>
• <vmw:ExtraConfig ovf:required="false" vmw:key="nvram" vmw:value="ovf:/file/file3"/>

• skipManifestCheck allows the OVA to be created after removing all the items in step 2. Without this command the OVF Tool won't be able to confirm the Manifest file and will error out.
  

I hope this helps people and that VMware acknowledges this as an issue they should address in some way.

[SuperCidal]

Seems more like a limitation on the web interface, Import-Vapp doesn't seem to have a problem with it.

[marvinmarcos]

Hi everyone,

A KB article exist also for this topic. It is Unable to deploy an OVF from a 6.7 environment (67724).