I'm experiencing the same issue, but I'm export from 6.5 and I have the same error when importing on older vCenter. Did you find a solution for this?
No I don‘t have a solution to this yet, sorry.
I need to do more tests when I find the time
vCenter must always be newer its ESXi hosts.
This has been discussed in the vSphere forums.
Also, I've never upgraded a host while it had VMs. I would vMotion them away to another host, do the ESXi upgrade, then vMotion them back.
I also have nightly backups of my vmdk's, but I've never had to restore them.
Restoring on a previous version of vCenter doesn't necessarily means the ESX are newer. OVA's are supposed to be portable, so you could in theory bundle a VM on a 6.5 vCenter and distribute it to other people using 6.0 for example, especially if the virtual hardware is compatible with older vcenter/ESX version.
I have the same issue and have been trying to get VMware Support to understand what the problem is but I can't seem to make them grasp what's going on.
To me it looks like 6.7 now supports UEFI Templates and due to that (I read this a few weeks ago but can't seem to fine the link now where I read it, so hopefully I'm correct with this...), when a template/VM is exported from 6.7 it includes the NVRAM file as well as a line in the vmx for the NVRAM location. This is great IF all your environments are 6.7, but most of us aren't that lucky, so because I've upgraded by internal cluster that I use for Template mangement to 6.7, I can no longer import any of our templates into a pre 6.7 environment without manually removing the NVRAM entry from the VMX file. While this workaround isn't a major issue, it's frustrating that I've been trying to explain this to VMware Support for 2 weeks now without success. I've even sent them links (like this thread) to others with the same issue.
VMware needs to add an option to export templates with support of UEFI or no support of UEFI so those of us without 6.7 in all our environments can still use a 6.7 environment to manage templates.
1 person found this helpful
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.
Thanks ethandlowry, I finally bit the bullet and integrated the modification in my packaging workflow.
# mkdir /tmp/ova # cd /tmp/ova # tar -xf /path/to/ova # sed -i "/ovf:\/file\/file3/d" *.ovf # tar -cf /path/to/ova *
That approach apparently isn't enough, the SHA checksum needs to be updated in the .mf file.
I tried to do it, and it passes the cheksum validation, but I have a weirder issue : even then, vsphere client still says I'm trying to import advanced option nvram but I don't know where it gets that from. Maybe it actually works but I have no pre-6.7 to test
I believe this is similar to the one discussed in this KB VMware Knowledge Base
With 6.7, the nvram boot file is introduced so if OVA is from 6.5 before P03, it may not work with 6.7.
1 person found this helpful
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:
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 (and deleting the manifest file; which should be recalculated in production):
- <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)?
yannbizeul and all; 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"/>
3. Delete MF and NVRAM files. I don't think this is 100% necessary, but I do it just to make sure it's clean.
4. Using the OVF Tool run the command ./ovftool --shaAlgorithm=sha1 --skipManifestCheck <Directory of OVF>\<OVF Name> <Directory to place OVA>\<OVA Name>
- shaAlgorithm=sha1 allows OVA to be imported into vSphere Client as client doesn't support sha256 which is the standard when exporting from 6.7. Without this command you can still import into Web Clients of previous versions, just not the vSphere Client.
- 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.
Here is what I ended up doing in my script, it works fine :
mkdir ovadir cd ovadir tar -xf ../myova.ova sed -i -E "/nvram/d" *.ovf' sed -i "/\.ovf/s/= .*/= `sha1sum *.ovf |cut -d " " -f 1`/;/nvram/d" *.mf rm -f *.nvram tar -cf ../myova.ova *
Nice one. I may borrow that script..:)
For those working with OVAs, this works just fine as long as you archive the files in the right order (see http://https://www.dmtf.org/sites/default/files/standards/documents/DSP0243_2.1.1.pdf section 5.3). The *.ovf must be in the beginning of the tarball and the *.mf at the end.
I just ran across this issue as well in our environment. Thanks for the direction as this helped get it working.
I did have to change up this script a bit, though. I know OVA's are primarily just zipped up contents but there's still a proper format as this code resulted in "missing an OVF descriptor" error.
I was able to get it working by using OVFtool to repackage the OVA after cleaning up OVF file. It still often failed because of the manifest file so I removed it as well. Now the OVA's work fine across both 6.5 and 6.7 vCenter servers.
Working code based on above code:
cd ovadir tar -xf myova.ova sed -i -E "/nvram/d" *.ovf sed -i "/\.ovf/s/= .*/= `sha1sum *.ovf |cut -d " " -f 1`/;/nvram/d" *.mf rm -f *.nvram *.ova *.mf ovftool myova.ovf myova.ova