Highlighted
Enthusiast
Enthusiast

6.5 fails to boot OVA imported VM because of bogus nvram file reference

Jump to solution

Not sure exactly what the problem is, if that's a problem exporting the VM or a bug in that specific 6.5 version.

I use ovftool on Linux to export a virtual appliance from vCenter 6.7.

When importing that VM to older versions (6.5, 6.0) people get warnings during the deployment about unsupported options, which is ok, but then they cannot boot the VM because it's looking for a nvram file that's nowhere to be found :

Could not create '/vmfs/volumes/5a53fd58-f488e6e0-4129-0025b5aa0000/nabox-test/ovf:/file/file3': msg.fileio.notfound

It doesn't seem this VMware Knowledge Base applies because my VM isn't EFI.

Thanks for your help.

Tags (3)
1 Solution

Accepted Solutions
Highlighted
Enthusiast
Enthusiast

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.

View solution in original post

14 Replies
Highlighted
Contributor
Contributor

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?

0 Kudos
Highlighted
Enthusiast
Enthusiast

No I don‘t have a solution to this yet, sorry.

I need to do more tests when I find the time

0 Kudos
Highlighted
Hot Shot
Hot Shot

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

View solution in original post

Highlighted
Enthusiast
Enthusiast

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

0 Kudos
Highlighted
Commander
Commander

Hello Ethan,

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.

Thanks,

MS

0 Kudos
Highlighted
Contributor
Contributor

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

Highlighted
Enthusiast
Enthusiast

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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 *

0 Kudos
Highlighted
Enthusiast
Enthusiast

Nice one. I may borrow that script..:)

0 Kudos
Highlighted
Contributor
Contributor

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.

0 Kudos
Highlighted
Expert
Expert

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

VCP5-DV twitter - @ericblee6 blog - http://vEric.me
0 Kudos