Description

VirtualBox 3.2.x appears to have introduced a bug related to OVF files whereby appliances exported from VirtualBox 3.2.x (on, e.g., a Mac host) no longer import properly on other platforms (e.g., a Windows host). Specifically, when we export an appliance with VirtualBox 3.2.6 (and 3.2.4) on a Mac 10.6.4 host, we then get this error when trying to start that appliance after importing it on a Windows 7 host running VirtualBox 3.2.6 (and 3.2.4):

The appliance we're exporting is configured with two virtual NICs: Adapter 1 is NAT, Adapter 2 is Host-Only. The above pertains to the latter.

A workaround appears to be, on the Windows host, to remove Adapter 2, then re-add it. Then the appliance starts.

The problem appears to derive from 3.2.x's introduction of the vbox namespace in OVF files. When we export an appliance on a Mac host, within the OVF file is this XML element:

<HostOnlyInterface name="vboxnet0"/>

However, the Windows version of VirtualBox 3.2.x appears to call that interface "VirtualBox Host-Only Ethernet Adapter". It *seems*, then, that, during import, VirtualBox 3.2.x might be relying unduly heavily on the vbox: namespace metadata, inasmuch as Windows expects that host to be called "VirtualBox Host-Only Ethernet Adapter" but instead sees it described as "vboxnet0"?

It's worth noting that removing all XML elements in the vbox: namespace from the OVF file prior to import also fixes the problem.

(A similar cross-platform problem appears to happen with AudioAdapter because of the vbox: metadata.)

Happy to provide additional details as needed.

Attachments

Change History

we encounter the same problem and are actully quite astonnished by this: the Open Virtualization Format was intrdocuded in order to enable the exchange of virtual appliances - also across vendors. In the current version it is however not even possible to exchange Virtual Box appliances created with the same version of Virtual Box across different platforms.
I hope, that the priority of this issue will be raised...