Crash Course in P2V Migration

One of the most-discussed advantages of virtualization is consolidation—the ability to merge many systems into a few. Organizations usually consolidate servers, thereby saving the business big money on maintaining expensive enterprise infrastructure. But infrastructure isn't always made up only of hardworking, powerful server equipment. Most organizations have evolved over time, as have a wide range of supporting systems, such that many business environments have legacy Windows-based workstations running a couple of applications in the traditional client/server model, servicing the handful of users who need those particular resources.

Historically, such systems are little workhorses. They sit in a corner beyond the attention of admins, happily humming and gathering dust—until that fateful day when the ancient hardware finally packs it in. Rather than waste time and effort rebuilding the system (after tracking down the only technician who knows anything about it), a neat solution is to make a snapshot of the entire thing and dump it into a virtual machine (VM). Then you can eliminate the old hardware, and the system gets a new lease on life with some decent resources.

The Problem
I faced this situation recently when a desktop that contained the company's security database reached the end of its lease. The current IT department wasn't involved in the system's installation, so we had little understanding of the product, and we potentially faced a large amount of downtime to rebuild it because we would have had to source new hardware and get third-party technicians out to handle the data transfer and to configure a new installation.

We were also worried about the security implications of sensitive data being stored on a physically accessible portable system, so we decided to perform a physical-to-virtual (P2V) migration to a VM running on Microsoft Hyper-V. The original system was a Pentium D-class desktop with 1GB of RAM running Windows XP Professional. Hyper-V fully supports this OS, and we were able to assign less RAM in the virtual environment because the original 1GB was overkill for the application’s needs.

We'd been running Hyper-V with Windows Server 2008 since April 2008, but we were still migrating our imaging procedure from Symantec Ghost Solution Suite to Windows Deployment Services (WDS). We had all the existing tools and utilities for ghosting but only a rudimentary WDS environment. It was mission-critical to minimize downtime, so we decided that we would move the system to Hyper-V using Ghost rather than Microsoft's imaging tools for WDS, and thereby take advantage of existing inhouse knowledge rather than spending time building WDS skills for this one task. If it had been a more complex and time-consuming task, we would have made the time investment to work with WDS.

The trick was to get the Ghost tools to the VM so that the system could talk back to the GhostCast server. We were deploying the DOS-based Ghost client across the network using WDS on Windows 2003 R2 in mixed-mode—the Symantec Ghost Boot Wizard lets you create bootable disk images using packet or network device interface specification (NDIS) 2.0 network drivers that are compatible with Microsoft Remote Installation Services (RIS). The Ghost images were stored on a central GhostCast server that clients were connected to. It's a simple setup and lightweight, although you're faced with the problem of creating a new boot image every time you need to support a new NIC.

Rather than tracking down compatible drivers for the virtual networking devices in Hyper-V, we decided to update things a bit and make use of Windows Preinstallation Environment (WinPE). The main advantages of WinPE in this situation were

• It's free
• It's based on the Windows kernel, so it's very flexible
• It supports multiple hardware platforms and devices
• It uses up-to-date hardware drivers
• A WinPE boot image can be used from CD-ROM, an ISO image, or over the network via WDS
• Did I mention it's free?

The Setup
Naturally, you'll need to make sure you have some prerequisites in place. To create a bootable WinPE image with the Ghost client and deploy it to a Hyper-V virtual system, you'll need the following:

• Windows Automated Installation Kit (WAIK), which is a free download from Microsoft.
• A Symantec GhostCast server, which can be any workstation with Ghost installed and enough disk space to hold your images—it certainly doesn't have to be an enterprise system. The version of Ghost doesn't matter, but the later versions have better file system support. The Ghost system can be a VM as well; the supporting platform doesn’t matter.
• Ghost32.exe, which is available on the GhostCast server. It's the 32-bit executable version of the Ghost client and runs as a standalone application.
• A Hyper-V VM. This VM should have a network adaptor attached, but it doesn't need to be a legacy network adaptor unless you're planning to boot from the network; it also needs at least one virtual hard disk and should be able to contact the GhostCast server via the virtual network. The VM can run on Server 2008 or Hyper-V Server.
• Vmguest.iso, the CD-ROM image containing the Hyper-V guest integration components and drivers for the virtual hardware platform, which is found at C:\Windows\System32 on the Hyper-V host.
• WDS running on Windows 2003 SP1 or Server 2008; OK, WDS isn't actually necessary because you can use a bootable CD-ROM (more on that later), but it's a useful way to deploy the WinPE image across the network.

First, download and install the WAIK to an administrative machine; this can be the GhostCast system if the OS is supported, or any other workstation. It's packaged as an ISO image, so you can mount the image, extract the contents, or burn it to a disk with a free tool such as InfraRecorder. From the AutoRun menu, select Windows AIK Setup. If the AutoRun menu doesn't launch automatically, double-click StartCD.exe.

After the WAIK is installed, create the WinPE working structure by going to Start, All Programs (on Windows Vista or Server 2008), Microsoft Windows AIK, Windows PE Tools Command Prompt to open a command window with various WinPE tools loaded into the system path for easy access. Use the copype command to create a WinPE structure:

copype x86 c:\winpe-x86 

As Figure 1 shows, this command creates the C:\winpe-x86 folder and extracts the necessary files for a 32-bit version of WinPE—the winpe.wim file, a Mount folder that you can use to mount the Windows Imaging Format (WIM) file via ImageX, an ISO folder that contains all the files needed to create a WinPE ISO image, and the BIN file needed to make the ISO image bootable. If you want to use a 64-bit boot environment, replace x86 in the code with amd64, but bear in mind that any applications or drivers you inject into the image must then also be 64-bit.

To customize the image, you need to access its contents. From the same command window, type the following command:

imagex /mountrw c:\winpe-x86\winpe.wim 1 c:\winpe-x86\mount 

As Figure 2 shows, this command mounts the first image contained in the WIM file in read/write mode to C:\winpe-x86. Browse to that folder and you'll see the WinPE file structure.

The next step is to inject the Hyper-V platform drivers into the image so that when the VM boots into WinPE, it will be able to see the network and fully support the VM’s hardware. From a networking perspective, the Hyper-V drivers are necessary for the synthetic NIC to function, but to boot a Hyper-V VM from the network, you must install a legacy network card, which doesn’t need extra drivers. However, injecting drivers is easy, and it’s good practice for later supporting different hardware platforms.

Mount the vmguest.iso image with a virtual drive utility such as DAEMON Tools or extract it with WinRAR or any other application that can read the contents of ISO files. Then, enter the following command in the WinPE command window:

peimg /inf=w:\support\x86\en-us\*.inf c:\winpe-x86\mount 

In this case, W:\ is the virtual drive I mounted the image in; you'll need to substitute the appropriate path for your system. Next, copy ghost32.exe:

xcopy PATH\ghost32.exe c:\winpe-x86\mount\windows\system32 

WinPE defaults to \Windows\System32 on boot, so ghost32.exe loads more easily if it's in that folder. As Figure 3 shows, you save the changes with the following command:

imagex /unmount /commit c:\winpe-x86\mount 

If you forget the /commit switch, none of your changes will be saved.