VMware Cloud Community
jeffprice1
Contributor
Contributor

ova fails to import, seems related to the BootOrderSection tag in the ovf

I've got an ova file that I've created with packer (via this plugin​) that imports fine into my local vCenter managed vSphere cluster. I'm on version 6.5. I've got reports that a customer was unable to import this ova into their similar cluster. I don't have any information about what version they're running. Locally, I was able to reproduce their error on an unrelated vSphere 6.5 instance that isn't under vCenter management.

When I try to import the ova, when I'm at the end ready to let it upload the ova, I get the following message:

screenshot-2018-10-16-16-54-54.png

If I continue anyway, the "upload" completes immediately and produces a VM that takes up no space and won't boot. After 5 minutes of thinking, vSphere seems to decide that it's broken and automatically deletes it.

Interestingly, I tracked it down to the following bit of xml in the ovf file inside the ova:

   <vmw:BootOrderSection vmw:instanceId="8" vmw:type="disk">

   <Info>Virtual hardware device boot order</Info>

   </vmw:BootOrderSection>

If I remove this, update the sha256 value in the manifest file, and re-tar the ova file, that one works fine on both of my environments.

I've attached the entire ovf file from my ova for reference, including what I believe to be the offending BootOrderSection tag.

Any one have any idea what's wrong with my standalone vSphere environment, or my customer's vCenter cluster that isn't showing up on my local vCenter cluster?

8 Replies
andremar
Contributor
Contributor

I managed to go around this issue by adding:

"bios.bootOrder": "cdrom"

to the "vmx_data" map in the packer json config file for the "vmware-iso" builder.

Section e.g.

"vmx_data": {

  "ethernet0.virtualDev": "vmxnet3",

  "ethernet0.networkName": "VM Network 1",

  "ethernet0.present": "true",

  "ethernet1.virtualDev": "vmxnet3",

  "ethernet1.networkName": "VM Network 2",

  "ethernet1.present": "true",

  "numvcpus":"4",

  "memSize": "8000",

  "bios.bootOrder": "cdrom"

},

jeffprice1
Contributor
Contributor

I still don't have a procedure for making packer behave the way I need, but I do have a report from my customer that a hand-crafted OVA that includes the OVF file edited to remove vmw:BootOrderSection tag worked in their environment.

It's important to note that the order of the files matters when using tar to create the OVA. The OVF file must be first, then the manifest, then the disk image.

Reply
0 Kudos
jeffprice1
Contributor
Contributor

Note that this is referring to the "vmware-iso" builder, which uses a local vmware to generate an OVA. I'm using "vsphere-iso" GitHub - jetbrains-infra/packer-builder-vsphere: Packer plugin for remote builds on VMware vSphere , which connects to a remove vsphere instance to generate an OVA. vsphere-iso doesn't seem to have a boot order property that I can customize.

Reply
0 Kudos
aaronklep
Contributor
Contributor

I see that project has this property.  Have you tried it? 

  • boot_order(string) - Priority of boot devices. Defaults to disk,cdrom

(from https://github.com/jetbrains-infra/packer-builder-vsphere​)

Reply
0 Kudos
aaronklep
Contributor
Contributor

That worked for me.  Thanks, andremar​ !

Reply
0 Kudos
aaronklep
Contributor
Contributor

By the way, I've found this doesn't seem to affect ESXi 6.7.  Only breaks with 6.5.

Reply
0 Kudos
aaronklep
Contributor
Contributor

What version of packer are you guys using?  I noticed this section wasn't in my build last month.  I think it may be a recent change to packer to add this section?  Not sure if it's an ovftool or packer issue or what.  Also, what hypervisor are you using for your builds?  What Guest OS?

Reply
0 Kudos
aaronklep
Contributor
Contributor

Reply
0 Kudos