OVA file made with VirtualBox 4.0 can't be read by VMware ovftool

[Ed Borasky]

I created a 32-bit openSUSE 11.3 virtual machine using VirtualBox 4.0.0 on a 64-bit openSUSE 11.3 host. The machine works fine. I then exported it to an OVA file using the Export wizard, which did not report any errors. But when I try to read it into VMware using VMware's "ovftool" conversion utility, "ovftool" reports an error:

znmeb@AlgoCompSynth:~/VirtualBox> ovftool Project\ Kipling.ova . Opening OVA source: Project Kipling.ova Opening VMX target: . Error: OVF Package is not supported by target:

• Line 25: Unsupported hardware family 'virtualbox-2.2'.

I've attached the XML 'ovf' file - it is indeed calling this a 'virtualbox-2.2' machine, which the VMware tools apparently do not support. I haven't checked the VMware documents yet to see what they do support, but I can do that if you don't have that filed away somewhere.

[Ed Borasky]

OVF file created by VirtualBox 4.0.0

[Technologov]

Added myself as CC.

-Technologov

[Christian Pötzsch]

Please make sure you use the latest version of ovftool. I just tried your ovf with ovftool 2.0.1 and it works without problems.

[Ed Borasky]

I've got ovftool 2.0.1 as well.

znmeb@AlgoCompSynth:~/Documents> ovftool --version
VMware ovftool 2.0.1 (build-260188)
znmeb@AlgoCompSynth:~/Documents> ovftool Project\ Kipling\ VirtualBox.ova 
Opening OVA source: Project Kipling VirtualBox.ova
OVF version:   1.0
Name:          Project Kipling VirtualBox

Download Size:        0 bytes

Deployment Sizes:
  Flat disks:         0 bytes
  Sparse disks:   Unknown
Networks:
  Name:        NAT
  Description: Logical network used by this appliance.

Virtual Hardware:
  Family:       virtualbox-2.2

Warning: No manifest file
Completed successfully
znmeb@AlgoCompSynth:~/Documents> ovftool Project\ Kipling\ VirtualBox.ova .
Opening OVA source: Project Kipling VirtualBox.ova
Opening VMX target: .
Error: OVF Package is not supported by target:
 - Line 25: Unsupported hardware family 'virtualbox-2.2'.

[leonbnu]

I have exactly the same problem.

[valve]

ovftool has a --lax commandline option which turns errors into warnings.

[stevet]

Issue still present in Virtualbox 4.1.8 and using ovftool 2.1. The --lax workaround still functions.

[diegows]

Same problem here.

I've change this line with the problem to:

<vssd:VirtualSystemType>vmx-06</vssd:VirtualSystemType>

And works.

Regards,

Diego

[Attila123]

I tried to change this VirtualSystemType. I am not yet familiar with ovftool, but using vSphere client with ESXi 4.1. Just for the record, with File -> Deploy OVF Template... I got: "File <...>.ovf fails integrity check and might have been corrupted during transfer.". Fortunately I selected the disk format to vmdk when I installed the VM. So I created a VM in ESXi without a virtual HDD, uploaded the vmdk (the one in the VM, not the exported one (that did not work)), added a new virtual HDD from existing file (from the vmdk just uploaded) and the VM worked.

Replying to diegows:

Same problem here.

I've change this line with the problem to:

<vssd:VirtualSystemType>vmx-06</vssd:VirtualSystemType>

And works.

Regards,

Diego

[eshizhan]

I write a little script do this:

​https://gist.github.com/eshizhan/6650285

[dragon788]

This issue exists because the v2 OVA/OVF that Virtualbox produces isn't recognized by VM's ovftool yet (they do 1.0 and 1.1), the DTMF does recognize v2 as a valid release though. As indicated above, the correct way to work around this is to 'vboxmanage export VM_NAME' or use the UI and select v1 when exporting, then use the ovftool to convert to VMX or a VMware compatible OVA by using 'ovftool --lax orig.ova dest.ova'.

[Bob Tanner]

Hey, look a 7 year old bug!

Using Virtualbox 5.2.2 r119230 Export Appliance..., Selecting Open Virtualization Format 1.0 results in:

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

Not recognized by VMCA 6.5 on OVF import.

Using Virtualbox 5.2.2 r119230 Export Appliance..., Selecting Open Virtualization Format 2.0 results in:

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

Not recognized by VMCA 6.5 on OVF import.

Using Virtualbox 5.2.2 r119230 Export Appliance..., Selecting Open Virtualization Format 0.9 results in:

<vssd:VirtualSystemType>vmx-6</vssd:VirtualSystemType>

This *is* recognized by VMCA 6.5 on OVF import.

As I read the spec VirtualSystemType can contain multiple entries, separated by a single space, would a simple fix be something like

<vssd:VirtualSystemType>virtualbox-2.2 vmx-6</vssd:VirtualSystemType>

Just wondering why this bug has not been resolved. It's 7 years old!

[Bob Tanner]

Looks like 5.2.4 makes things WORSE! The virtualization format 0.9 no longer works!

Using Virtualbox 5.2.4 r119785 Export Appliance..., Selecting Open Virtualization Format 0.9 results in:

<vssd:VirtualSystemType>vmx-6</vssd:VirtualSystemType>

But OVF import on VMCA 6.5 throws an error, "OVF 0.9 is not supported. Invalid name space"

Using Virtualbox 5.2.4 r119785 Export Appliance..., Selecting Open Virtualization Format 1.0, create manifest file checked results in:

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

Throws error invalid OVF checksum algorithm: SHA1

Using Virtualbox 5.2.4 r119785 Export Appliance..., Selecting Open Virtualization Format 1.0, create manifest file NOT checked results in:

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

Not recognized by VMCA 6.5 on OVF import.

Using Virtualbox 5.2.4 r119785 Export Appliance..., Selecting Open Virtualization Format 2.0, create manifest file checked results in:

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

Throws error invalid OVF checksum algorithm: SHA256

Using Virtualbox 5.2.4 r119785 Export Appliance..., Selecting Open Virtualization Format 2.0, create manifest file NOT checked results in:

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

Not recognized by VMCA 6.5 on OVF import.

[VVP]

hi BasicTheProgram,

1. Where did you read about "VirtualSystemType" syntax? please, give a link.

2. Who is throwing the errors "invalid OVF checksum algorithm: SHA256" and "invalid OVF checksum algorithm: SHA1 "?

[Bob Tanner]

​https://www.vmware.com/pdf/ovf_spec_draft.pdf

VMCA 6.5 when I attempt to upload the OVF into the Content Library.

[VVP]

​https://www.vmware.com/pdf/ovf_spec_draft.pdf is a very old (first) variant of OVF standard. Anyway, there are no clauses or statements in this document about multiple values inside the section "VirtualSystemType".

We can't say anything about VMCA 6.5 logic and conformance to OVF standard. Try to create OVA package in the VMCA 6.5 and next import one into VirtualBox. Will be there the similar error concerning checksum or not?

[Bob Tanner]

How about ​https://www.dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.1.pdf

"...Zero or more virtual system type identifiers may be specified separated by single space character..."

683 The vssd:VirtualSystemType element specifies a virtual system type identifier, which is an
684 implementation defined string that uniquely identifies the type of the virtual system. For example, a virtual
685 system type identifier could be vmx-4 for VMware’s fourth-generation virtual hardware or xen-3 for Xen’s
686 third-generation virtual hardware. Zero or more virtual system type identifiers may be specified separated
687 by single space character. In order for the OVF virtual system to be deployable on a target platform, the
688 virtual machine on the target platform is should support at least one of the virtual system types identified
689 in the vssd:VirtualSystemType elements. The virtual system type identifiers specified in
690 vssd:VirtualSystemType elements are expected to be matched against the values of property
691 VirtualSystemTypesSupported of CIM class CIM_VirtualSystemManagementCapabilities.

[VainVogon]

Since I just had exported a ESXi VM (v6.7U2) so I could re-import it (to essentially clone it) I checked the 'vssd:VirtualSystemType' entry in the ovf-file.
It read <vssd:VirtualSystemType>vmx-14</vssd:VirtualSystemType>

So I changed the VirtualSystemType in my Virtualbox ovf-export (exported as Open Virtualization Format 1.0) to this value and tried to add it to my ESXi setup. No more complaints about drive type, but it gave an error about device type 35 - apparently the sound card. I deleted the complete entry for that from the ovf-file, and then I was able to add this VM to my ESXi system without any errors.

[wish it would work]

13 years and this bug hasn't been fixed. Changing VirtualSystemType to either vmx-06 or vmx-14 did not resolve the error for me. Since solving errors but simply turning off error messages is a bad idea, I'm not even going to try importing with the loosened restrictions. I'm just going to rebuild my VM from scratch in VMware and use VMware, since this makes me feel like VirtualBox isn't reliable if I need to get my data out of it, and knowing that bugs go almost a decade and a half without being fixed doesn't give me the confidence I need to depend on it.