virtualbox.org

I have read posts here, and consulted a number of articles on websites, and am still having difficulty in exporting from VirtualBox for use in VMware Player.
I am in VBox 6.0, and using VMware Player 14.0. The export supports three versions of export: OVF 0.9, 1.0, and 2.0. (From memory, as I am running an export as I type this.)
As both VBox and VMware have had OVF support for years, I assume that OVF 2.0 should be OK. But if not, please advise.

Is it better to export to OVA, or to OVF with separate files?

I tried first to export to an OVA, and when I try to open in VMware Player, it complains:
Line 72: Unsupported element 'Storage Item'
Line 81: Unsupported element 'Storage Item'
Line 90: Unsupported element 'Storage Item'
Line 99: Unsupported element 'EthernetPortItem'

What can I do to make this work?

Thanks,

I have never tried. (I am not a fan of VMWare), but the first things I would do would be to remove the guest additions and clear the check mark from the Enable Network Adapter box for all the NICs. The NICs will be different in VMWare and the guest additions will interfere with PCTools. Each virtualization program needs its own optimising additions which should be removed before you switch to a different program. PCTools is almost impossible to remove afterwards.

I just did a test on my system. Exporting as OVA works fine with either 1.0 or 2.0 .

I am also not a fan of VMware, but in my office, that puts me in the minority. I have built a VM in VirtualBox which supports the migration of a very large project from an older to a much newer development environment, and now need it to be available to others. The choice was between replicating the functionality in a similar VMware image, or simply exporting form my fully functional VBox VM. I initially tried the replication, but ran into some unexpected issues, so elected to try the export approach.

Exporting is tedious, as the VM is large, and each export takes about an hour to complete. The first was to an OVA, using OVF 2.0. Failure. Then to OVF, also in 2.0. Failure. Finally, after looking in the generated small XML file, I saw the items there which provoked the errors. Exported to OVF using level 1.0, and those items were absent. So it seems that for export, the later format is not necessarily a benefit. Had I modified the settings in my VBox VM, perhaps 2.0 would have worked. But using 1.0, and no mods, also worked.

Great, thanks for the feedback, good to know... Marking as [Resolved].

I know you've marked it RESOLVED but I thought I'd throw in my experience.

I've had fair experience exporting and found a direct export to be tedious and time consuming. In one instance it went great. Instead of exporting to OVF/A from Virtualbox I first removed the guest additions and just ran a Macrium Reflect backup of the OS. I recreated the OS in VMWare by restoring the image to a new VMWare VM - I usually had to use IDE disk controllers if it wasn't already - and got it tweaked to run in VMWare. THEN I exported the OS as an OVF/A for subsequent import into other users VMWare environment.

No crossing "boundaries" that way and it produced a working template that we deployed in quite a few places.

An interesting approach nonetheless!
I'm not sure what this method does with the hard disk UUIDs and hardware UUIDs, and if that requires a re-activation on the guest...

True on both counts. I typically redo the UUIDS anyway and we have an internal activation server, so for me at least there was nothing extra to do, others would have to reactivate. In my case it was a small server that we wanted to deploy in several locations globally. It made it the fastest way to deploy it. I had a working model n VB and it was decided to deploy it in VMWare. Had I realized it was going to be used as is I would have developed it on VMWare, however space was at a premium on my only available local VMWare server.