I have been trying to convert a physical Windows 2000 server running on SCSI RAID to run inside a virtual machine. Given my interest in digital evidence, I was interested in achieving the conversion (which is popuarly referred to as Physical To Virtual or P2V conversion) from first principles.
A while ago I came across the Windows Dynamic Disk partitioning scheme (also called Dynamic Disk or LDM). It’s support under linux is slowly gaining momentum, but still remains a bugbear for manipulating disks. So just to complicate things, I decided to convert the physical host’s drive to using Dynamic Disks.
My proposed methodology was as follows:
1. Use a live CD (helix) to acquire the source drive to a external SATA drive. This included recording the partition and disk geometry using the sfdisk program, recording the LDM partition information using the ldminfo tool from the Linux NTFS project, and imaging the drive using dcfldd.
2. Load the image onto the Linux host running VMWare Server.
3. Generate a VMWare Virtual Disk file which works with the image.
4. Create and configure a VM using the new virtual disk.
5. Fixup the drivers inside the VM using the Ultimate P2V method.
In practise this didn’t work as planned. What I was presented with was the following:
A blank screen with a non flashing cursor on boot.
Looking into the problem in more detail it appeared that the boot problem was due to a difference in disk geometry between the SMART2 RAID controller present in the the physical host and VMWare’s emulated SCSI hard drives. As it turns out VMWARE will only emulate a disk with 63 sectors per track, and 255 heads (the number of cylinders from this perspective is irrelevant). My RAID controller however presented a disk with 32 sectors per track, and the 255 heads. Fdisk showed me this:
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
Running sfdisk inside the virtual machine with this image resulted with a number of warnings about partitions not being aligned on cylinder boundaries.
It appeared that this problem was related to the differences in geometry between the two drives. On boot, the boot code in the MBR of the hard drive is looking inside the image at the wrong point. It appears that the Boot code can only boot partitions that are aligned on cylinder boundaries, ie. the start address of partitions must be fully divisible by heads*sectors. The differences between these means that the boot code is looking in the wrong place inside my image.
[Update: I am not sure about this after researching this some more... it appears that some old versions of DOS required that partitions be cylinder aligned, but the MBR boot code appears like it is independent of cylinder alignment.]