Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

July 01, 2009 12:00 AM

Crash Course in P2V Migration

You've got a workstation, Hyper-V, and Symantec Ghost--here's how you get from A to B using C
Windows IT Pro
InstantDoc ID #102339
Rating: (6)

Executive Summary:
Most businesses have evolved such that they include old workstations running legacy OSs and applications. Physical-to-virtual (P2V) migration can be just what you need to preserve these systems. Here's a procedure to rescue such a legacy system, using Symantec Ghost Solution Suite to move the old OS and applications to a Microsoft Hyper-V virtual machine (VM). The procedure also takes advantage of Windows Deployment Services (WDS) and Windows Preinstallation Environment (WinPE).


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.

Related Content:

ARTICLE TOOLS

Comments
  • Bret
    3 years ago
    Oct 21, 2009

    Hi James,

    Here's a thought: If you're doing a P2V for NT4, Win2k or WinXP from a single (ie. UNI) core processor to a multi-core processor (ie. MP), you may need to replace the virtual machine's HALs (and a couple other files) if you virtual machine has multiprocessor support. Here are some links:
    NT:
    http://support.microsoft.com/kb/142660

    XP:
    http://incore.net/winxp-multicpu/

    From what I understand, Vista and Win7 can auto detect the number of processor cores and manual intervention is not required.

    Regards,
    Bret

  • Joshua
    3 years ago
    Jul 19, 2009

    Jared & James,
    There is a missing step in the above How-to. After you are done with the steps that are on Page 1 of this article you need to also complete this command:

    copy c:\\winpe-x86\\winpe.wim c:\\winpe-x86\\iso\\sources\\boot.wim, Then Y

    This needs to be executed prior to the oscdimg command for the changes that you did to the winpe.wim to be copied to the ISO file. I found this when attempting to add defrag.exe to a WinPE file and it was also useful when doing my P2V migration with Ghost. Post back if you have any questions.

  • jared
    3 years ago
    Jul 14, 2009

    James,
    The only way I know of checking the contents of the WIM file is by mounting it to a temp directory. If I do that then the answer is "Yes" the Ghost32.exe file IS listed under \\Windows\\System32.
    I installed daemon tools however when I mount the ISO I see only the CDROM files/folders: BOOT, EFI, SOURCES, BOOTMGR.

  • James
    3 years ago
    Jul 13, 2009

    jaredt - the oscdimg command just makes use of whatever is contained within the WIM file. Can you double-check that the ghost32.exe is definitely being written to the WIM file using the /commit command? Another thing to check is to mount the created ISO with Daemon Tools to see whether the file was written to the ISO - let me know how you go.

  • jared
    3 years ago
    Jul 10, 2009

    You guide was fairly straight forward and simple however when the WinPE iso boots ghost32.exe is not loaded. If I "dir" the X:\\windows\\system32 folder its not listed but if I mount the c:\\win_pe folder back on my pc I can see the file is in the directory. Why would it should in the directory but not get copied over when I call the oscdimg command?

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.