VMware Cloud Community
yannbizeul
Enthusiast
Enthusiast
Jump to solution

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

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
ethandlowry
Enthusiast
Enthusiast
Jump to solution

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

17 Replies
AxiansItaly
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos
yannbizeul
Enthusiast
Enthusiast
Jump to solution

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

I need to do more tests when I find the time

Reply
0 Kudos
Dave_the_Wave
Hot Shot
Hot Shot
Jump to solution

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.

Reply
0 Kudos
yannbizeul
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
ethandlowry
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
ethandlowry
Enthusiast
Enthusiast
Jump to solution

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.

yannbizeul
Enthusiast
Enthusiast
Jump to solution

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

Reply
0 Kudos
msripada
Virtuoso
Virtuoso
Jump to solution

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

Reply
0 Kudos
brianstock
Contributor
Contributor
Jump to solution

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

ethandlowry
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
yannbizeul
Enthusiast
Enthusiast
Jump to solution

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 *

Reply
0 Kudos
ethandlowry
Enthusiast
Enthusiast
Jump to solution

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

Reply
0 Kudos
inetlequest
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
JayhawkEric
Expert
Expert
Jump to solution

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
Reply
0 Kudos
imrejonk
Contributor
Contributor
Jump to solution

Hi, I'm a bit late to the party. Hopefully this will help someone who's having the same issue. We solved this using the latest ovftool (4.4.1), which has a --noNvramFile flag. It does exactly what you'd expect: the nvram file and all references to it are excluded from the OVA file, allowing you to use it without any issues on pre-6.7 hypervisors.

Reply
0 Kudos
sunder3480
Contributor
Contributor
Jump to solution

I am using vcenter 7, and as per the information i remove the entry on OVF file , it was successfully imported

 

thanks

Reply
0 Kudos
sunder3480
Contributor
Contributor
Jump to solution

Solved with the comments on vcenter 7

Reply
0 Kudos