Crash Course in P2V Migration

Finalize WinPE
After you've customized WinPE, you have two choices. First, you can create a bootable ISO image from the modified WIM file, which you can then either attach to the VM within Hyper-V Manager or burn to disk. Burning a disk is slower than using an ISO image, but a Hyper-V VM can read from physical media so you could use the disk on other systems. To create an ISO image, type the following command in the WinPE command window:

oscdimg -bc:\winpe-x86\etfsboot.com -n -o c:\winpe-x86\iso c:\winpe-x86.iso 

The command outputs the image as winpe-x86.iso. To attach it to a VM, make sure that the Hyper-V host can access the ISO image, then open Hyper-V Manager. Right-click the VM, then select Settings. In the left-hand window under IDE Controller 1, select DVD Drive. Next, in the right-hand window, select Image file, then browse for the ISO image. Click OK to confirm.

Your second option after customizing WinPE is to make it available over the network via WDS. To do this, you need a configured WDS server—either Windows 2003 SP1 or Server 2008. Copy C:\winpe-x86\winpe.wim to the WDS server, then launch the WDS management console on the server.

Expand the tree and right-click Boot images. Select Add Boot Image, browse for the winpe.wim file, click OK, then Next. Enter an appropriate image name and description (or accept the defaults), click Next, then Next again. WDS adds the image file to the list of available boot images. Make sure the VM is on a network that can find the WDS server and boot it from the network, then choose the image in the boot menu, as Figure 4 shows.

Prep the Physical System
Now it's time to get the physical system ready to take a snapshot. You should start by performing a thorough cleanup of the system. I didn't do enough of this and paid the price later with a mind-numbing repair installation. Go through Add/Remove Programs and strip out all driver packages—graphics drivers, network drivers, and so on; they won't be needed on the VM. Keep only what you need to maintain basic functionality.

It's also a good idea to do a disk cleanup and defrag on the hard drive—this is always a good idea before imaging because the process arranges data better on the disk, which results in fewer problems during image transfer. Also, go into System Configuration (Start, Run, msconfig) and disable all startup applications—when the VM comes online for the first time, it won't be fully functional until the Hyper-V Integration Services are installed, so it's better to prevent startup software from running until the system is stable.

If you're moving from a physical system with an IDE hard disk to a VM with an IDE virtual disk, chances are that the image will restore easily onto the VM. If, however, the physical system has a RAID controller or SATA drive, there's a strong likelihood that a straight image up/image down procedure will result in a VM that instantly bluescreens due to a change in the disk controller on the boot disk. You're most likely to have this problem on earlier OSs such as Windows XP and Windows 2000; Vista should cope.

However, because we're rescuing legacy systems, there's a strong chance you're dealing with an older OS. Therefore, you can save yourself a lot of time and bother by using Sysprep. Performing a basic Sysprep on the physical system to trigger the mini-setup gets you past any bluescreen problems when the VM reboots after image deployment. If you want a more elegant solution, incorporate the contents of the \support\x86\en-us folder into the file system on the physical machine before running Sysprep so that the virtual device drivers are present when the guest OS runs through plug-and-play detection. However, you still have to install the Integration Services software after imaging—there's more to the package than just the drivers, such as data exchange, heartbeat, and time synchronization.

Because I was in a rush to get my system migrated, I didn't run Sysprep and paid the price when the VM instantly bluescreened. A repair install fixed the problem, but it took so long that it would have been worth spending the time to go back, run Sysprep on the machine, and recapture the image.

Deploy the Image
When you've prepared the physical system, shut it down and boot into the Ghost client. If you don't have a pre-existing method in place for this procedure, you can use the custom WinPE ISO image created earlier. Or, if the older system supports network booting, let it access the image from the WDS server. You can even take the bootable ISO image and transfer it to a USB key and boot the physical system from that—which makes a great portable tool.

To create an image, open the GhostCast server application and select Create Image. Nominate a session name and file name. Then from the client, go to GhostCast, Unicast and enter the session name to begin the capture session. After it's captured, it's good practice to open the capture file with Ghost Explorer on the GhostCast system to make sure the image files are OK.

When you've created the image, fire up the VM on the Hyper-V host and boot into WinPE, as Figure 5 shows. Remember that if you're booting from the network, you need to attach a legacy network adapter. When the system loads, you’ll be presented with a command window. Navigate to X:\Windows\System32 and enter ghost32.exe to launch Ghost, as Figure 6 shows.

If the VM and GhostCast system are on different subnets, you'll have to enter the server IP address manually for the client to connect. If you're planning to do more ghosting across subnets, consider entering an IP helper address on the router so that you don't have to type in the IP address every time. Wait while the image is restored, then reboot the VM. The only post-install task needed for system stability is to install the Integration Service components—then you're done.

Next Time?
This method of P2V is, to be honest, not exactly elegant. However, it does have the advantage of being quite robust—using Ghost for imaging means that if something goes horribly wrong with the VM, you've still got both the original machine (obviously, don't throw it away until you complete the migration successfully!) and the captured image, so you haven't lost any data.

This method also has the advantage of letting you get your hands dirty with WinPE and WDS. They're a powerful combination and can form the basis of a wide range of custom tools for supporting systems. WinPE is a great platform for deploying useful utilities to any corner of your network, physical or virtual—like ghost32.exe.

Would I follow the same path next time? As long as we still have a supporting Ghost infrastructure, yes. After we've moved across to WDS completely, no. There are ways of converting a physical hard disk to a VHD that you can then attach to a Hyper-V VM—that's a much more straightforward (although apparently equally time-consuming) process, and certainly worth a look. The other, more sensible, option is to make use of System Center Virtual Machine Manager (SCVMM), which has supported P2V methodologies. The downside is that SCVMM is an extra purchase, and businesses that are just playing with Hyper-V at this stage might not consider the cost worth it. If, however, you're considering Hyper-V as your virtualization platform of choice, SCVMM is an invaluable management tool and should definitely be investigated.