You would think converting a virtual machine from one format to another would be simple. Especially when there are multiple blogs out there on how to do it. But, of course not – so time for another misadventure in computing post. I was asked by a colleague to get a copy of a demo virtual machine for some upcoming analyst activities. The problem: my colleague’s system is a Surface 2 Pro running Hyper-V on Windows 8.1. And the source system was a personal Retina MacBook Pro running Parallels 9. And the VM is running Windows Server 2012 R2.
The core issue was that the source image in Parallels was a virtual UEFI system with a GPT partition table. The destination image was a Gen 1 Hyper-V VM with a virtual BIOS, which necessitates a MBR partition table. (I was unable to get the Gen 2 Hyper-V VM that supports UEFI to work given the differences in hardware drivers.)
The first problem is actually converting the disk file itself, as they are in very different formats. And the steps of using VMWare and VirtualBox utilities to do the conversion did not work – I ended up with a corrupt virtual hard disk (probably because of this GPT issue).
So to do this, I found the awesome Disk2VHD utility from SysInternals (http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx). With this utility, I ran it and chose not to grab anything except the C:\ partition and voila – I created a new VHD that I was able to load up on my Hyper-V server and at least not have corruption.
Then, the fun of trying to get it to boot began. The normal way to fix a modern Windows system that will not boot is:
- Boot from Windows installation image
- Go to Command Prompt
- Enter the following commands:
- “bootrec /fixmbr”
- “bootrec /fixboot”
- “bootrec /scanos”
- “bootrec /rebuildbcd” – except this critical last step fails because the partition table is not MBR.
So, you have to convert the partition table to MBR. And that’s where life gets interesting. After trial and error, I found the following to be the best way to do this without losing data:
- Download the latest Live x86_x64 Fedora image from http://www.fedoraproject.org/. Yes, you really need a live Linux image because of a really handy utility called gdisk.
- Boot the VM with the Fedora Live image and login to the desktop.
- Run the Terminal utility.
- Then, run the following commands:
- “su -” – get into administrator mode
- “yum -y install gdisk” – actually install the gdisk utility
- “gdisk /dev/sda” – start running gdisk against the virtual hard drive
- “r” – to enter gdisk recovery/transformation mode
- “g” – to convert from GPT to MBR
- “p” to preview the converted MBR partition table
- “w” – to write changes to disk.
- At this point, the VM can be rebooted with Windows installation media to get to a Command Prompt to fix the rest of the problems. Once there:
- “diskpart” – enters the Windows disk partition utility
- “select disk 0” – selects the boot drive
- “list partition” – should show the disk partitions present. The largest one is the actual one that you want to boot. It is probably going to be the third or forth partition on the disk. In my case it was the fourth.
- “select partition 4” – select the partition we want to boot.
- “active” – to mark the partition as active in MBR.
- “exit” – to exit diskpart
- The next step is to find the actual disk itself – it is probably going to be D:\ (at least it was on my system) because of the reserved GPT partitions in advance of the actual usable partition. Once you determine the drive letter, you can proceed as follows:
- “bootsect d: /nt52 /force /mbr” – makes D: bootable.
- “bootrec /fixboot” – fixes core startup environment
- “bootrec /fixmbr” – fixes core startup environment
- “bootrec /scanos” – find the OS; note it will probably be D:\Windows in my example (and this is OK)
- “bootrec /rebuildbcd” – update the BCD environment; note it will be D:\Windows in my example (and this is OK)
- At this point the system can be rebooted without any installation media – and it should just boot up with everything in C:\Windows\ as it should be. Once booted:
- Uninstall Parallels Tools
- Install Hyper-V Integration Services (if required – not applicable on this system since Windows Server 2012 R2 has them built-in)
- Reactivate Windows
And voila! I hope this helps.