Post by pinnerite
$ ovftool "/path/to/oiginal_vm.vmx" "/path/to/export.ovf"
will create an ovf file. It does. When an attempt is made to import
appliance (odd choice of descriptor) in VirtualBox, the ovf file reads in
the the original vmware file and if i am correct, creates its own vdi
Unfortunately when an attempt is made to start it, it fails.
This is typical. The only source of advice that I found claims that the
disk geometry (the disk is a file in this case) its geometry is skewed.
The solution was to read the original CHS parameters from the VBox.log
$ vbox-img geometry --filename "Windows 10 x64".vdi --format VDI --
cylinders 7830 --heads 255 --sectors 63
The 7930/255/63 came from the LCHS in thr Vbox.log file.
Well, I did it all several times with an XP and Win-10 VMs but nothiing
The reason for posting here is that someone may have cracked it.
"VMware Workstation 5.0 What Files Make Up a Virtual Machine?"
This is the primary configuration file, which stores settings chosen
in the New Virtual Machine Wizard or virtual machine settings editor.
If you created the virtual machine under an earlier version of VMware
Workstation on a Linux host, this file may have a .cfg extension"
The implication, is the OVFtool reads the configuration, to get the
names of all the components. For example, the "disk container" of the VM
is the .vmdk file. And that file, it's possible VirtualBox reads
that directly. So if you had say Mint running in VirtualBox, you
went to the storage settings menu and "added" the .vmdk file as a
disk drive, it would be seen (and perhaps even available for
automount, for running gnome-disks or gparted or whatever).
On the Virtualbox side, the .ova is the appliance file, similar
to a ZIP. The contents are
some.vmdk # disk container 4.5GB
some.ovf # config file 11KB
The OVF file is an XML text file, which looks slightly more complicated
than the usual XML config file for a virtual machine. The section at
the end though, has the usual stuff. You can see here, there is
no mention of CHS geometry.
<File ovf:href="baloney.vmdk" ovf:id="file1"/> <=== fileref to UUID linkage...
<Info>List of the virtual disks used in the package</Info>
<Disk ovf:capacity="42949672960" ovf:diskId="vmdisk1"
<StorageController name="IDE Controller" type="PIIX4" PortCount="2" useHostIOCache="true" Bootable="true">
<AttachedDevice type="HardDisk" hotpluggable="false" port="0" device="0">
The "ovf:format" seems to be referencing VMDK as the format
of the included file. I see no suggestion in this example,
of an "on-the-fly" conversion. VBoxManage doesn't have
a completely orthogonal capability when it comes to file
formats, and its capabilities have varied with VirtualBox
When the appliance is decompressed, the .ovf file would be
read and converted into a regular XML configuration file
that VirtualBox uses (.vbox).
Summary: I don't see the disk container being touched at all
in this. There must be some inherent problem with
the disk container, and it's not something any
I'm sure you have plenty of reference sources for comparing
containerization. This is the only one I know off hand.
For example, you can get a Win7 in all these appliance formats,
which would then be unpack-able in their respective hosting
softwares. You could then compare the disks in each of
these, to see how "munged" they are, when compared. But
thats a few GB of downloads.
But that's only necessary, if you were doing what I just
did, which was take apart an item for a look, look at
the XML files and so on.
No mention at all of geometry in there. It's inherent to
how the disk was defined in the first place.
Just going into your favorite Host, use a Guest, add
a port to a disk controller and connect up the .vmdk
and use your disk tools, you should be able to check
various aspects of what's in there. I see nothing
in the XML files I've just looked at, suggesting
a root cause within them. But since any sort of
optional lines could appear in XML files, have a
look in yours. The small config files are just
text and they won't bite :-)