Received wisdom says that using VMware's ovftool, along the linews of:

$ 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
file.

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
file and then apply them to the generated vdi. with something like:

$ 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 worked.

The reason for posting here is that someone may have cracked it.

Here's hoping.


--
Mint 20.0, kernel 5.4.0-45-generic, Cinnamon 4.6.7
running on an AMD Phenom II X4 Black edition processor with 8GB of DRAM.

--- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

It is a bit unclear to me why you would be asking a question about
Windows in various Linux groups?
Perhaps you could help by telling us exactly what your system is.
Note that CHS makes no sense for a "disk" that is actually a file. A
file can be scattered all around the disk.
You ask this question in 4 Linux groups. What is the system that you are actually running?

On 2020-10-08, pinnerite <pinnerite@gmail.com> wrote:

Received wisdom says that using VMware's ovftool, along the linews of:

$ 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
file.

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
file and then apply them to the generated vdi. with something like:

$ 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 worked.

The reason for posting here is that someone may have cracked it.

Here's hoping.

--- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

pinnerite wrote:

Received wisdom says that using VMware's ovftool, along the linews of:

$ 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
file.

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
file and then apply them to the generated vdi. with something like:

$ 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 worked.

The reason for posting here is that someone may have cracked it.

Here's hoping.

"VMware Workstation 5.0 What Files Make Up a Virtual Machine?"

https://www.vmware.com/support/ws5/doc/ws_learning_files_in_a_vm.html

".vmx <vmname>.vmx

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.

<References>
<File ovf:href="baloney.vmdk" ovf:id="file1"/> <=== fileref to UUID linkage...
</References>

<DiskSection>
<Info>List of the virtual disks used in the package</Info>
<Disk ovf:capacity="42949672960" ovf:diskId="vmdisk1"
ovf:fileRef="file1"

ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOpt imized"
vbox:uuid="313e735f-0176-4112-ae0a-d2ac61426b86"/>
</DiskSection>

<StorageControllers>
<StorageController name="IDE Controller" type="PIIX4" PortCount="2" useHostIOCache="true" Bootable="true">
<AttachedDevice type="HardDisk" hotpluggable="false" port="0" device="0">
<Image uuid="{313e735f-0176-4112-ae0a-d2ac61426b86}"/>
</AttachedDevice>

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
version.

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
"OVFtool" did.

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.

https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

VirtualBox
Vagrant
VMWare
HyperV
Parallels

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 :-)

Paul

--- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 08/10/2020 04:43 pm, pinnerite wrote:

Received wisdom says that using VMware's ovftool, along the linews of:

$ 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
file.

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
file and then apply them to the generated vdi. with something like:

$ 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 worked.

The reason for posting here is that someone may have cracked it.

Here's hoping.

Why do you need to convert it? Can you not just use the VMWare .vmdk
(i.e. the disk file) in VirtualBox?

https://smallbusiness.chron.com/open-vmdk-virtualbox-28847.html
or
https://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/


--

Chris Elvidge, England

--- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

pinnerite wrote:

Received wisdom says that using VMware's ovftool, along the linews of:

$ 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
file.

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
file and then apply them to the generated vdi. with something like:

$ 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 worked.

The reason for posting here is that someone may have cracked it.

Here's hoping.

I found an example of such a case here.

https://forums.virtualbox.org/viewtopic.php?f=1&t=63454

The entire disk is using 56 sectors instead of 63 sectors.

There was a hack back in WinXP days, where if you set
the sectors to 56 on the WinXP *partition*, I think it had a
positive effect on the alignment of clusters with
regard to the usage of 512e disk drives. That was a reason
to be toying with the number 56.

You'd need to find a posting from that era with more
details as to how that was done.

*******

Looking into the issue, it seems some geometry information
comes from BIOS calls. If you look at Testdisk source,
it hints at it there. VirtualBox has a skeletal BIOS
too, and has to emulate sufficient behaviors of
a real BIOS (EINT 0x13), to get something booted (it also
has to provide runtime services, such as the BIOS call in this
case that may be providing geometry info.

I wasn't able to figure out, when the BIOS is doing this,
where the putative CHS value for the whole disk is stored.
Some file systems have geometry info for a partition
stored within them. Large disks today are based on
LBA (logical block address) concepts.

CHS seems to pop up all over the place - it seems to infect
every level of design, with comic results.

The Microsoft document with the "standard" for VHD containers,
it contains an algo in the appendix for working out a CHS value
to be put in the header of the VHD file. And the code comment
says that it implements "rounding down" as a strategy. IDK,
maybe they feel lucky doing that or something. That might be
an attempt to leave a larger slack at the end of the
virtual drive or something.

Paul


--- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)