So given the withdrawal of Vmware Converter, and the first P2V in 5 years, I thought I'd give Starwind V2V converter a try. The experience was mixed, and I'd throw some feedback this way to maybe assist others, or, potentially, highlight my own lack of technical acumen
I did 2 conversions, one went pear shaped, and one went ok, with a fair bit of massage.
The scenario was a P2V of a physical server, running Windows Server 2008 R2. Storage was a single physical drive, MBR partition style, with 2 primary partitions. Simple enough I'd think.
The server was located more or less on the other side of the globe, the connection not ligthning fast, and no direct connection to vCenter or ESX possible, so the selected method was to simply convert the disk and add it to a new VM once the VMDK's was transfered to a datastore.
First Attempt (failed):
- Converted logical volumes, one by one, to separate volumes into separate harddisks. Figured the easiest way was to do it a migration time.
- The converted harddisks suffered from partition table issues.
- They could be read from a booted WIndows Install image.
- No partition was set to Active
- They could not be changed using DiskPart, so it wasn't possible to set a partition active.
- Attempting fix with bootrec /FixMbr smashed the partition table up for good.
- Converted entire harddrive.
However the resulting VMDK descriptor files had some flaws in that regard:
- Configured as thin provisioned, even though the disk was obviously thick
- VMFS extent had an offset configured (this is an incorrect configuration, VMFS extents do not use offsets)
- Configured for IDE controller, including IDE geometry (not exactly an error - but ... well...) *
Now I wouldn't call it an error producing disks with a target controller type of "IDE", but this isn't really what we wan't for any modern Windows OS.
Luckily I hadn't forgot how to hand edit VMDK descriptors, so I'd convert it to "lsilogic", adjust the geometry accordingly, remove the thinprovisioned setting and the VMFS extent offset... after that it booted like a charm.
So I don't really need support, I am however curious as to why the target controller type defaults to IDE, anno 2022.
Below you can find the original VMDK descriptor, and the edited one.
Cheers.
Original Disk Descriptor:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=2f8ab2e2
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 286677120 VMFS "ConvertedDisk-flat.vmdk" 0
# The Disk Data Base
#DDB
ddb.adapterType = "ide"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "742816e9287602798b86c80e2f8ab2e2"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 98 93 3b 59 d9-94 e9 69 b4 0f 60 73 84"
ddb.virtualHWVersion = "4"
Corrected Disk Descriptor:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=2f8ab2e2
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 286677120 VMFS "ConvertedDisk-flat.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "17844"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "742816e9287602798b86c80e2f8ab2e2"
ddb.uuid = "60 00 C2 98 93 3b 59 d9-94 e9 69 b4 0f 60 73 84"
ddb.virtualHWVersion = "4"