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:”path\Source.xml” /
name:vm_name /vmconfigpath:”vm
path” /virtualDiskPath:”vm path” /
hwdestvs:controller_server
In this script, path\Source.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: P2VSource\TestServer.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 VSMT\p2v\TESTMIGRATION.
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 Files\Microsoft ADS\NBS Repository\User\PreSystem. 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 Files\Microsoft VSMT p2v\TestMigration. 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 Files\Microsoft
VSMT\p2v\TestMigration. Execute the Test-
Migration_CreateVM.cmd script. The script
creates a new virtual machine configuration
file E:\VMS\TestMigration\TestMigration
.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
khohal May 09, 2008 (Article Rating: