Executive Summary: |
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.
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.