10 Steps for Physical to Virtual OS Migration

If you’re up against a tight OS migration deadline, you’ll be a hero if you have a fully functional and tested physical to virtual (P2V) solution on a server that you can take anywhere in your organization. A P2V solution lets you perform a migration with no impact on or reconfiguration of your production network. I’ll explain the inner workings of the Microsoft Virtual Server Migration Toolkit (VSMT) and demonstrate how to configure a mobile server using ADS for the P2V migration.

I’ll pick up where I left off in this series. In “ADS Unplugged” (October 2006, InstantDoc ID 93625), I showed how to build a basic mobile ADS solution for Windows OS migrations. Then, in the Web-exclusive article, “Kick Your Mobile ADS Solution Up a Notch” (February 2007, InstantDoc ID 94982), I went over how to install VSMT to extend the mobile ADS solution to perform physical machine to virtual machine migrations. Now I’ll demonstrate how to use VSMT to perform a P2V machine migration.

Before You Begin
Using this series of articles, you’ve seen how to create a mobile ADS solution by assembling the necessary hardware on a movable cart and installing the basic software: Windows Server 2003 Enterprise Edition, Dynamic Host Configuration Protocol (DCHP) Server, ADS 1.1, Virtual Server 2005 R2 SP1, and VSMT 1.1. I call the source server Testserver, and I assume it’s running Windows Server 2003, Enterprise. To perform a P2V migration, you need to follow 10 steps, as I’ll show in this article.

Before you begin, put some time into deciding whether your servers are good candidates for a P2V conversion. Sometimes it’s not worth it to perform a P2V migration on an unstable production server because the instability issue just comes along during the migration. If this is the case, it might be better to rebuild the virtual machine from scratch and move the data from the old physical server to the new virtual server. In addition for servers that have OEM system applications, you should uninstall or disable them before you attempt a P2V migration to ensure that they will not interfere with the virtual machine on first boot.

Are your servers are good candidates for a P2V conversion? If so, you’re ready to get started.

Step 1: Prepare the Source System
Although VSMT doesn’t modify the source system, I recommend that you follow the best practiceof backing up the source system before you start the P2V migration process. In addition, disableany drivers or applications that are specific to thephysical hardware and that won’t be available in thevirtual machine environment.

Step 2: Prepare the MobileP2V Server
VSMT includes a tool called GatherHW.exe that collects the physical hardware information on the source server and creates an XML configuration file you can use to analyze the source server for any known hardware incompatibilities in the source system (dynamic disks, more than 3.6 GB RAM, unsupported devices, and so forth). To run GatherHW.exe, you must copy it to the source system. I recommend creating a share called VSMT on the MobileP2V server in the VSMT installation folder, which is by default C:Program FilesMicrosoft VSMT. You’ll also need a place to store the XML files that GatherHW.exe produces, so create a directory called C:P2VSource on MobileP2V and share it as P2VSource, specifying local administrator write permissions.

Here’s quick summary of the MobileP2V server drive configurations you’ll be using: C drive (C: - operating system), D drive (D: - ADS image files), and E drive (E: - virtual machine storage).

Step 3: Gather the Configuration Information
Once you’ve created the shares on the MobileP2V server, log on to Testserver as the local administrator. Then, create a directory called C:VSMT, and map a network drive to \MobileP2VVSMT. Copy GatherHW.exe to C:VSMT. Double-click GatherHW .exe on the source system to collect the configuration information. GatherHW.exe creates an XML file with the name of the source system (e.g., Testserver.xml) in the directory. Copy the XML file to \MobileP2V P2VSource.

Step 4: Validate the Configuration Information
After collecting the configuration information from Testserver with GatherHW.exe, use VMScript.exe (which was installed on Mobile P2V as part of VSMT) to validate the data. To run VMScript.exe against the XML file, log on to the MobileP2V server and open a command prompt. Change directory to C:Program FilesMicrosoft VSMT. In the command window, execute the VMScript by typing:

 VMScript.exe /hwvalidate /hwinfofile:”C:  P2VSourceTestserver.xml”

VMScript analyzes the XML file and reports any errors or configuration issues with the source hardware. (Note that some server hardware such as special add-in boards, USB-attached devices, and other devices—such fiber channel host bus adapters— won’t work on virtual machines.)

Examine the VMScript output for any issues, warnings, or errors. Use Vmpatch.exe to correct any issues and copy any missing system files, service packs, or hotfix files before continuing. If you receive the following error regarding missing Windows Server 2003 Service Pack 2 (SP2) files, see the sidebar, “Adding Windows Server 2003 SP2 Support to the VSMT Patch Directory,” for how to update the patch cache with Windows 2003 SP2 drivers.

Error: Cannot find patch files for the operating system/service pack level in the C: Program FilesMicrosoft VSMTPatches Source5.2.3790SP2 directory.

Continued on page 2

Step 5: Generate the Migration Scripts
After you’ve resolved any issues with the Testserver configuration and you’ve rerun VMScript until there are no blocking issues, generate the migration scripts. These scripts control disk image capture, virtual machine creation, and disk image deployment to the virtual machine. To generate the migration script, run VMScript with the following syntax:

 VMScript /hwgeneratep2v /  hwinfofile:”pathSource.xml” /  name:vm_name /vmconfigpath:”vm  path” /virtualDiskPath:”vm path” /  hwdestvs:controller_server

In this script, pathSource.xml is the path to the xml configuration file (C:P2VSource TestServer.xml), vm_name is the name to assign to the virtual machine in the Virtual Server console (TESTMIGRATION), vm path is the location where you want the .vmc and the .vhd files to be stored on the specified host (E:VMs), and controller_server is the name of the Virtual Server host (MobileP2V).

By default, the migration scripts are configured to create fixed-size virtual hard disks. If the physical disks on the source system have an extensive amount of unallocated free space or you don’t want to use fixed-size virtual hard disks, execute VMScript with the / virtualDisk-Dynamic option. This option also speeds up the virtual machine creation process. If you use /virtualDisk- Dynamic the command line looks like:

 VMScript /hwgeneratep2v /hwinfofile:”C:  P2VSourceTestServer.xml” /  name:TESTMIGRATION /vmconfigpath:”E:  VMs” /virtualDiskPath:” E:VMs” /  hwdestvs:MOBILEP2V /virtualDiskDynamic

VMScript.exe generates the migration scripts in a subdirectory, C:Program Files Microsoft VSMTp2vTESTMIGRATION. Execute the VMScript command line, and you’ll see the output shown in Figure 1. VMScript creates 12 output files that are used during the migration process. The readme file, TestMigration_P2V_Readme .txt, provides information about script creation and driver issues. The three XML files contain information used during the migration about the hard disk and driver configuration. The TestMigration_ boot.ini file is a copy of the boot.ini information from the source machine. You’ll execute three scripts directly during the migration process: TestMigration_ Capture.cmd captures the source disk drives into ADS images, Test- Migration_CreateVM.cmd creates the target virtual machine using the source configuration information, and TestMigration_ DeployVM.cmd images the captured source disk images to the target VM drives.

VMScript also creates a subdirectory called Patches. It is automatically populated with known patches that you’ll need to install.

Step 6: Load the Required Drivers into ADS
When VMScript validates the source system configuration information, it doesn’t validate that all the required drivers are installed in the ADS file cache. The most important driver to install is the source system network card. Without this driver, the source server can’t be captured. Download the latest network interface card drivers for the source system to a temporary directory on MobileP2V. Copy the driver files into C:Program FilesMicrosoft ADSNBS RepositoryUserPreSystem. When you copy the network interface card driver files into the ADS file cache, don’t create any subdirectories or include Txtsetup.oem files. The subdirectories aren’t needed because the driver files must be placed directly in the PreSystem directory, and the Txtsetup.oem file isn’t used.

After you’ve copied the files, restart the ADS Builder service so that it finds the new drivers. Open a command window and type

 net stop adsbuilder

Then press Enter. Type

 net start adsbuilder

Then press Enter.

Step 7: Capture the Testserver System Disk
Now you’re ready to capture the Testserver system disk images. The TestMigration_Capture. cmd migration script executes and leverages ADS to capture each disk image sequentially. Log on to MobileP2V as local administrator and follow these steps to start the disk image capture process of TestServer. Open a command window and change directories to C:Program FilesMicrosoft VSMT p2vTestMigration. Execute the TestMigration_ capture.cmd script. When prompted, log on to the source server, Testserver, restart it, and boot it to the Pre-execution Environment (PXE) interface.

ADS takes control of the source system and boots it into the Deployment Agent to initiate the disk image capture. To follow the progress of each disk image capture, you can use the Automated Deployment Service MMC snap-in on the Controller server. In the MMC snap-in, go to Devices, Running Jobs, then double-click on the running job, as shown in Figure 2. Image captures can take awhile depending on the size and number of the disks. If the server has a slow network interface, consider updating the interface card to a faster card connected to a faster port to reduce the transfer time. When the image captures are complete, ADS shuts down and removes the source system from the device database. The last task before the script terminates is changing system file attributes, as shown in Figure 3.

Step 8: Create the Virtual Machine
Before you migrate the captured disk images, you must create the virtual machine and configure it with the same memory, disk, and network configuration as the physical machine. The TestMigration_CreateVM.cmd script (one of the scripts that VMScript generates) automates this for you. To launch the script, open a command window and change directories to C:Program FilesMicrosoft VSMTp2vTestMigration. Execute the Test- Migration_CreateVM.cmd script. The script creates a new virtual machine configuration file E:VMSTestMigrationTestMigration .vmc, registers the virtual machine, connects the virtual machine to the default virtual network VM0, creates and attaches the virtual hard disks (VHDs) to the virtual machine, and attaches a Remote Installation Services (RIS) virtual floppy disk to the virtual floppy drive. If you get this error

Error:System.IO.FileLoadException: The located assembly’s manifest definition with the name ‘Microsoft.VirtualServer.Interop’ does not match the assembly reference.

then the MobileP2V server is running Virtual Server 2005 R2 Service Pack 1(SP1). VSMT 1.1 is compatible with Virtual Server 2005 R2 but not Virtual Server 2005 R2 SP1, Refer to the sidebar, “Why VSMT 1.1 Doesn’t Support Virtual Server 2005 R2 SP1,” for more information on how to resolve this issue.

When all these tasks are complete, check the ADS device database using the ADS MMC snap-in. The virtual machine should have been added to the ADS device database and set to boot to the Deployment Agent.

Continued on page 3

Step 9: Deploy the ADS Disk Images to the TestMigration Virtual Machine
After the virtual machine is created, the source server disk images must be restored. TestMigration_DeployVM.cmd controls this part of the migration procedure. To restore the source disk images and deploy the virtual machine, go to C:Program FilesMicrosoft VSMTp2vTestMigration and execute

 TestMigration_DeployVM.cmd

To follow the progress of the virtual machine deployment, you can use the Virtual Server 2005 R2 Administration Website on the Controller server. You’ll see the virtual machine boot into the Deployment Agent and the disk images restore to the virtual hard disks, as shown in Figure 4. The hardware-dependent system files are then swapped for virtual machine-compatible versions, and required operating system configuration settings are applied.

If you use the MMC snap-in to check the ADS device database, you’ll see that the virtual machine is still in the device database. The TestMigration_DeployVM.cmd script terminates after removing the RIS virtual floppy disk from the virtual machine. The virtual machine remains booted in the Deployment Agent.

Step 10: Complete the Migration Process
Before you complete the source system to virtual machine migration process, perform a few final cleanup tasks. The TestMigration virtual machine is still booted into the Deployment Agent, so you need to reboot it: Open the ADS MMC snap-in, select and right-click the TestMigration device, then select run job. A New Job wizard launches. Click Next. Select to create a one-time job, and click Next. Then click Next to skip the description screen. Select Internal command, and click Next. Select bmonitor reboot, and click Next. Click Finish to reboot the TestMigration VM.

Once the machine is rebooted, release control of the device, and delete the virtual machine from the device database. Log on to the virtual machine, and install the Virtual Machine Additions to get keyboard and mouse integration and better performance. Complete any remaining configuration modifications, and test the virtual machine connectivity and performance to ensure that it’s running as expected. Once the virtual machine testing is complete, migrate TestMigration from the MobileP2V solution to the production Virtual Server host. Once you do that, you can back up and delete the source system disk images from the ADS image store.

Now you have a fully functional and tested MobileP2V solution that you can take to any part of your organization and perform a P2V migration. So go virtualize!

Author’s Note: The instructions for the migration have been adapted from the Virtual Server 2005 R2 Resource Kit from Microsoft Press co-authored by Janique Carbone and me.