I've been working on a server consolidation project over the past few months in preparation for moving a small corporate server room into a hosted data centre. I spent much of last night and this morning working on one of the final milestones, P2V (physical-to-virtual conversion) of a bare metal Windows 2008 system running SQL Server 2008.
All of our previous bare metal Windows systems have been virtualised with the VMware converter, but is was a newer server than most (an IBM x3650 M2), and it has EFI firmware rather than a traditional BIOS. VMware does not support P2V of GPT systems, so we were stuck with finding another method. There have been reports that people have done it successfully however (with appropriate repairs of the MBR and the boot sector), so we had good reason to believe it was possible.
Our bare-metal Linux servers had been virtualised with a basic disk copy technique:
- boot Ubuntu live CD on source and destination
- install ssh server on destination
- Run on source: dd if=/dev/sda bs=1024k | ssh destination 'dd of=/dev/sda bs=1024k'
This was quite effective for our Linux servers, since Linux distributions tend to include drivers in their initial RAM disks for the SCSI controllers that VMware emulates. I decided to try the same thing at the partition level to get the Windows system copied: create the new partitions on the destination, copy the individual partitions, and then repair the Windows boot process.
I'll claim bad memory about what happened around this point (it was late, and i was tired), but it was not successful. After a little searching, i came up against a parted alternative called GPT fdisk (known as gdisk in Ubuntu), which claimed to be able to convert from GPT to MBR partition types, as long as the drive was a supported size (which this one was). So i started a copy of the entire drive using the dd process described above, and went to bed, leaving the 500 GB server to copy overnight.
This morning, after a little messing around with different versions of the Ubuntu live CD to find a more recent version of gdisk, i was able to convert my partition table using a hybrid partition table (which the author takes pains to point out: don't try this at home, kids). GPT fdisk allows selecting which GPT partitions to represent in the MBR, so i simply selected all of the Windows drives, without the reserved partitions at the beginning. (This wastes whatever space was taken by those partitions, but 400 MB out of 500 GB was not too high a price to pay for avoiding backing out this change and waiting for the next maintenance window to have another crack at converting this system.)
As expected, the Windows VM would not boot. I booted from the Server 2008 DVD and performed a repair of the MBR and boot sector using bootrec.exe. This got little further along in the boot process, resulting in the error message that "BOOTMGR is missing". Fortunately, this is a known problem with a straightforward fix: startrep.exe.
This got the system booting, but after loading several device drivers it produced a blue screen STOP 0x0000007B. Searches on VMware suggested this was a disk driver issue, and a common problem after P2V conversions. Unfortunately, VMware's advice about it was to inject the drivers on the source server, and re-run the P2V conversion, which i wasn't prepared to do due to the multi-hour copy process involved.
Enter the offline registry editor. This 4 MB boot CD allows Windows password resets and general registry edits without needing Windows to be running. Armed with the knowledge that the LSI SAS driver was likely already installed, i found that simply enabling the driver (by setting HKLMSYSTEMCurrentControlSetservicesLSI_SASStart to 0!) was all that was needed. This is a little confusing in the offline registry editor because SYSTEM is not the default registry hive (you have to select it manually), and there is no "CurrentControlSet", only "ControlSet001" and "ControlSet003" on the system i was converting. (I enabled the LSI SAS driver in both ControlSets.) After this, Windows 2008 was able to boot successfully in our ESXi 5 system.
After installing VMware tools, we tried the paravirtual SCSI driver, but that caused a blue screen again, so we reverted to the LSI SAS driver, which on this system has offered pretty good performance anyway. The paravirtual NIC driver (vmxnet3) seems to work fine.
Looking back, i can't help but think that i probably could have done this better, by creating the MBR partitions manually and persevering longer with getting it booted that way, or by investigating VMware's support for UEFI/GPT within VMs, or maybe there are even pre-built tools out there to manage this. But this experience served to reinforce to me that despite several seemingly large obstacles, lots of problems are soluble with persistence and logic. And Microsoft and VMware's knowledge bases. And people documenting their experiences on forums. And great Free Software tools that solve specific problems. And Linux live CDs. And Google. :-)