You can convert a dd image to a vmware vmdk with this tool by clicking here. To test it paste in the tool output in the walk-through below.
Using a live cd, such as Helix or Knoppix, create a dd image of the hard drive or raid array to be virtualized. It is assumed that the reader has enough problem solving ability or UNIX experience to determine the hard drive device of the machine in question.
The following example assumes imaging a system with a COMPAQ SMART2 array controller as the primary disk array. Its device is /dev/c0d0.
root@foo:/root # sfdisk -luS | tee sfdisk.c0d0 Disk /dev/ida/c0d0: 8711 cylinders, 255 heads, 32 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/ida/c0d0p1 32 73439 73408 12 Compaq diagnostics /dev/ida/c0d0p2 * 73440 20555039 20481600 42 SFS /dev/ida/c0d0p3 20555040 71081759 50526720 42 SFS /dev/ida/c0d0p4 0 - 0 0 Empty root@foo:/root # dcfldd if=/dev/c0d0 of=c0d0.dd bs=512 conv=noerror,sync hashwindow=0 hashlog=c0d0.md5.txt root@foo:/root # cat c0d0.md5.txt Total (md5): 8842802a3578d146bb2cb58ff1bf22f3 root@foo:/root # md5sum c0d0.dd 8842802a3578d146bb2cb58ff1bf22f3 c0d0.dd root@foo:/root #
At this point we have an image of the source disk, and a copy of the output of sfdisk (which importantly, we ran using its sector based addressing mode). Visiting the online tool d2vmdk we enter the name of the imaged device ( /dev/c0d0 ) and the name of the file containing the image ( c0d0.dd ).
We next open up the file containing the output of sfdisk from earlier. The tool prompts us to paste in this output:
Disk /dev/ida/c0d0: 8711 cylinders, 255 heads, 32 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/ida/c0d0p1 32 73439 73408 12 Compaq diagnostics /dev/ida/c0d0p2 * 73440 20555039 20481600 42 SFS /dev/ida/c0d0p3 20555040 71081759 50526720 42 SFS /dev/ida/c0d0p4 0 - 0 0 Empty
At this point, the disk inspects the disk geometry and partition layout from the contents of what was just pasted. In this case, the tool notes that the geometry of the source disk is different to that of the target disk. Fixing up these geometry related differences is the tool's primary purpose.
In this case, the tool also notes that the disk likely contains Windows Logical Disk Manager (LDM) or Dynamic Disks ( The two "SFS" partitions are indicators of this). In order to extract out the LDM partitions correctly, the tool needs more information. In this case, it asks for the output of the ldminfo tool, which has been created as a part of the Linux-NTFS project. The LDM parts of this project are currently very beta, but the ldminfo tool provides enough information in this case. We run ldminfo against the image, and paste the output into the tool. (A binary of ldminfo, suitable for running in a live CD is linked in the resources section of the page)
Device | Offset Bytes Sectors MiB | Size Bytes Sectors MiB -------------+--------------------------------+------------------------------- c0d0.dd | 0 0 0 | 36393861120 71081760 34707 c0d0.dd1 | 37601280 73440 35 | 10486579200 20481600 10000 c0d0.dd2 | 10524180480 20555040 10036 | 4718592000 9216000 4500 c0d0.dd3 | 15242772480 29771040 14536 | 21149777920 41308160 20170
The new partition layout is presented in the next screen.
The main heavy lifting of the application is now performed. After comparing the two disk geometries, the tool creates a plan for creating a new virtual disk (or set of disks if there are more than 4 partitions). The new virtual disk(s) has the following properties:
The next screen presents a set of commands which may be pasted into a UNIX command line on the new virtual machine host. The commands copy the partitions into their own files, and generate blank gaps in between partitions to ensure cylinder alignment. A new blank partition table is created, then sfdisk is used to create a new partition table. Finally, the NTFS boot sector is fixed.
The next screen contains the contents of a VMware Virtual Disk definition file, which is to be copied and pasted into a file with a .vmdk extension. This disk definition contains all of the information necessary to create a virtual disk from the previous step.
Booting the disk at this point in a VM will result in a Blue Screen, of type INACCESSIBLE_BOOT_DEVICE, as the VMWare Virtual SCSI drivers are likely not loaded into the OS. At this point updating the drivers inside the VM is all that is needed to get the machine fully up and running. My choice was to use the free UltimateP2V method.