Data Centers

SolutionBase: Migrate old Windows NT 4.0 servers to VS2005 with the Virtual Server Migration Tool

Deploying virtual machines in your organization can save you hardware costs and administration headaches. Microsoft has made the transition to virtual machines on Virtual Server 2005 easier with the Virtual Server Migration Tool. Here's how to consolidate old Windows NT servers on one machine using VSMT.

Suppose you have some old Windows NT 4 domain controllers sitting in your data center that you need to continue to maintain. Or, maybe you have some lightly used Windows Server 2003 machines humming along on their own hardware solely because the applications on those servers don't behave well with other applications. Maintenance on those old NT 4 machines can start to add up, and running small apps on dedicated hardware can be pretty inefficient.

One way to consolidate those applications without having to completely rebuild your infrastructure from the foundation is to migrate legacy and small applications to virtual servers using Virtual Server 2005. As a free add-on to Virtual Server 2005, Microsoft also provides the Virtual Server Migration Tool (VSMT), which helps you migrate physical servers to a virtual equivalent without losing data or functionality.

What does it do?

Simply put, VSMT copies your physical server to a new virtual server while simultaneously replacing the physical server's hardware abstraction layer (HAL) with a HAL that contains the virtualized hardware used by Virtual Server 2005. If you have servers with strange hardware that your server relies on to do its job, you may not be able to use VSMT. But if you just have a software application running on a standard server, you shouldn't have any trouble "virtualizing" your physical server.

The process for virtualizing a physical server involves these steps:

  • Gather hardware information from the physical server to be virtualized.
  • Use gathered data to create a virtual server with similar specs.
  • Migrate the physical server to its virtual counterpart.
  • Verify the success of the migration.

Prerequisites

VSMT supports virtualization of servers running Windows NT 4.0 SP6a, Windows 2000 Server SP4, and Windows Server 2003 systems. To use VSMT, your environment must meet some prerequisites:

  • You must have at least one Virtual Server 2005 installation on a reasonable server.
  • Automated Deployment Services (ADS) should be installed on a Windows Server 2003 Enterprise system. ADS can be installed on the same server as VS2005, as long as that server is running the Enterprise Edition of Windows Server 2003. Although the three ADS componentsï¿?the controller, imaging, and network boot servicesï¿?can be installed on separate servers, for VSMT, all three services need to run on a single server.
  • If you plan to migrate a Windows NT 4.0 server to Virtual Server 2005, you need to install the Windows Management Instrumentation core on the NT server prior to migration. WMI is used extensively by the migration process.
  • If you want life to be easier, install ADS on the same server you're using for Virtual Server 2005. Better yet, use a smaller server (for migrations only) onto which you also install ADS and VS2005. Once the migration is complete, move the virtual machine files to your production VS2005 system and bring the virtual server to life on that machine. This way, you get the simplicity of a single server solution without any performance or resource impact on your production VS2005 system. This article uses a single server solution for ADS and VS2005.
  • The machine you plan to migrate must have at least 96 MB of RAM to accommodate the migration tools.

A word of warningï¿?

If you're reading this article with the intent to virtualize just one or two small physical servers, I highly recommend that you stop reading and just migrate the servers manually by doing a reinstall under VS2005. VSMT is extremely complex, and you might end up spending more time getting this going than actually reinstalling. If, on the other hand, you're going to be regularly virtualizing servers, read on.

ADS installation

ADS refers to an add-on for Windows Server 2003 called Automated Deployment Services. It doesn't, in this instance, stand for Active Directory Services, as this acronym sometimes implies. It might have been nice if Microsoft had made this a little less confusing. ADS is designed to make server rollouts easier for administrators by automating as much of the process as possible. ADS serves this role, but in a unique way. Instead of rolling out a new physical server, ADS assists with the virtualization process of an existing server.

I won't delve into ADS or its installation, but I'll provide a snapshot of this service. You can find out more about ADS by reading the article "Automatically deploy Windows Server 2003." For the purposes of this article, I'll just discuss how to quickly get ADS up and running.

ADS itself is broken up into three services: the controller, imaging, and network boot services. However, ADS itself is only one part of the infrastructure requirements for this service. You also need a database and an administration program. The MS SQL desktop engine, shipped with ADS, fits the first requirement. An administration program, also shipped with ADS, fulfills the second.

To get started, download ADS from Microsoft's Web site. This article assumes that you'll install the whole of ADS on a single server. For this sample, I installed ADS onto a virtual Windows Server 2003 Enterprise system running inside Virtual Server 2005. Since I rarely need ADS, I don't need to dedicate an entire physical server to it.

Note: You don't have to use the desktop version of SQL Server, since ADS supports the full version product. There is a lot to ADS that isn't covered in this article. In fact, if you're running Remote Installation Services or PXE boot services on your network, stop here before you continue with the ADS installation. Continuing might result in these other services failing to work correctly.

Start the ADS installation by expanding the downloaded file and running the setup utility. A typical Microsoft installer will start. The first step is to install the SQL desktop engine database. Just follow the prompts on the screen to do this. It's pretty straightforward and takes less than a minute.

As for ADS itself, the complete installation includes both ADS and the related administration utility. The first screen of the ADS installation asks you to identify the database server to use (Figure A). For this example, I'm using the MSDE installation.

Figure A

ADS database selection

Next, specify a location in which ADS can find the Windows Server 2003 setup files. I just copied the I386 directory from a Windows Server 2003 CD for this purpose and placed the files at C:\setupfiles\i386.

Finally, I opted to store Windows boot images at C:\images before the ADS installation commenced. Once the ADS installation completed, all ADS components were installed and ready to go.

In my lab environment, I'm running ADS, VSMT, and VS2005 all on the same server. Running these services on separate servers requires you to take additional steps. Refer to the Microsoft-supplied VSMT whitepaper for additional information on separating these services.

Installing VSMT

With ADS in place, install the VSMT package that you downloaded from Microsoft's Web site. All of the prerequisites are in place, and the package includes some scripts that automate some of the work coming up. The installation is very straightforward and standard. For this example, I accepted all of the defaults, which installed VSMT to C:\Program Files\Microsoft VSMT.

Create a virtual network

During the migration process, a virtual network named VM0 is used for communication with a newly created virtual server. If this network doesn't exist on the Virtual Server machine, you need to create it in order for any migrations to be successful.

There are two ways to create the virtual network: at the VS2005 Web console or using a Microsoft-supplied script.

VS2005 Web console

To create this network, open the Virtual Server Web console and choose Virtual Networks | Create. Create a network named VM0 and make sure to associate it with the same physical network adapter used for ADS, as shown in Figure B. In my lab, I have Virtual Server 2005 and ADS on a server with only a single network adapter, so this isn't an issue.

Figure B

Create a virtual network named VM0 for migrations.

Microsoft-supplied script

Microsoft ships a VB script that automates the creation of this virtual network inside Virtual Server 2005. On the server that you've installed the VSMT component on, run the following command, which assumes that you've opted for a default installation of VSMT:

C:\Program Files\Microsoft VSMT\Samples\cscript CreateVirtualNetwork.vbs 

Migration

There are four steps involved in a successful migration from a physical server to a virtual server:

  • Gather hardware information about the server to migrate.
  • Validate the hardware configuration and create custom scripts based on this configuration.
  • Run the generated scripts. You have to run a minimum of three scripts.
  • Install the virtual machine additions on the newly created virtual server.

Gather hardware information about the server to migrate

The VSMT product includes a program called gatherhw.exe, which, as you might guess, gathers information about the hardware present on the system that you plan to virtualize. From the server you wish to virtualize, map a drive to the server housing the VSMT components. From a command prompt, execute the command on the next line, after which you'll get the information below.

<Drive>:\Program Files\Microsoft VSMT>gatherhw Microsoft (R) Virtual Server Migration Toolkit - Gather H/W Tool version 541.0 Copyright (C) 2004 Microsoft Corporation. All rights reserved.  Writing configuration information to file: 'FILE4.xml'Connected to WMI. Gathering Information. Please Wait.
Gathering System Summary.
Gathering Controller Info: 'IDE'.
Gathering Controller Info: 'SCSI'.
Gathering Disk Information.
Gathering Logical Drive Information.
Gathering Mounted Devices Information.
Gathering Network Information.
Gathering Video Information.
Gathering Parallel Port Information.
Gathering Sound Card Information.
Gathering CDROM Information.
Gathering Serial Port Information.
Gathering Services Information.
Gathering Driver Information.
Gathering Run Section Information.
Gathering Hotfix Information. 

Success.

You should keep the generated information for further processing. 

For this example, I also copied the XML file back to the VS2005 server and into the C: \Program Files\Microsoft VSMT directory for later processing. I found it easier to do as much work right on the VS2005 machine as possible. The XML file has the same name as that of the server on which you ran gatherhw.exe.

Validate the hardware configuration and create custom scripts

These steps are all performed at the VS2005 console. Once you've gathered the hardware information, you need to verify that VSMT can actually use it; then generate scripts that will perform the brunt of the migration work for you.

C:\Program Files\Microsoft VSMT>vmscript
/hwvalidate /hwInfoFile:file4.xml

Microsoft (R) Virtual Server Migration Toolkit - VmScript Tool ver.6.0.541.0 Copyright (C) 2004 Microsoft Corporation. All rights reserved.

Parsing file: file4.xml

Checking configuration for incompatibilities.
No incompatibilities found.

Success.

In this example, notice that there were no incompatibilities found in the target server's hardware configuration. With this success under my belt, I can move on to generating the scripts that will be used next. For my installation, I used the following command for this step:

C:\Program Files\Microsoft VSMT>vmscript /hwGenerateP2V
/name:file4 /vmConfigPath:"C:\Documents and Settings\All
Users\Documents\Shared Virtual Machines" /virtualDiskPath:
"C:\Documents and Settings\All Users\Documents\Shared
Virtual Machines" /hwDestVS:2003ent /vmmemory:256
/hwInfoFile:file4.xml

This probably looks pretty complicated, but it's really not. With the exception of one parameter, all of these are required for this step. Only the vmmemory parameter could have been omitted. All are explained below. If you want a full list of the options, use "vmscript /hwGenerateP2V /?" instead.

  • /hwGenerateP2V: Tells the vmscript executable to actually generate scripts this time around.
  • /name:file4: A name unique on your VS2005 system by which the newly migrated machine will be known. I used the same name as the physical server since I don't already have a virtual machine named "file4."
  • /vmConfigPath:"C:\Documents and Settings\All Users\Documents\Shared Virtual Machines": The path on the VS2005 server in which the virtual machine configuration file will be stored.
  • /virtualDiskPath:"C:\Documents and Settings\All Users\Documents\Shared Virtual Machines": The path on the VS2005 server in which the virtual machine disk files will be stored.
  • /hwDestVS:2003ent: The name of the VS2005 server to which this machine will be migrated.
  • /hwInfoFile:file4.xml: The XML file generated earlier.

Run the generated scripts

This step is broken down into three parts. First, run the "capture" script generated in the previous step.

C:\Program Files\Microsoft VSMT\p2v\file4\file_capture.cmd 

This command script queues up everything necessary to boot your target server to a deployment agent, capture images of the hard drives on the target server, and then shut down the target server after deployment. If you look at the ADS console at this point, you'll notice that a new device has been added with the same name as your target server.

Now, you need to boot your target server from the network using either the server NIC's onboard PXE utilities or a PXE boot disk that you create. For this example, my sample server's NIC has PXE capability. If yours does, go to the server's BIOS and change the boot device order so that the Network option is on top. If you're planning to use a PXE floppy, change the boot order so your server boots from a floppy disk first. Regardless of the method you choose, you'll eventually get to a screen that looks like the one shown in Figure C.

Figure C

Your target server's hard drives are being copied to your virtual server.

When you're done, your target server will shut down automatically. Note that this part can take quite a while depending on the size of the hard drives on the target server.

After this process completes, you can move on to the next script, which sets up the new virtual machine inside VS2005 and attaches a new disk image as the first hard disk. For my setup, the following command achieves this task and the resulting virtual machine is shown in Figure D.

C:\Program Files\Microsoft VSMT\p2v\file4\file4_createvm 

Figure D

The new machine automatically connects to the new VHD file.

The disk image isn't the one that was just pulled from the target server. It's an empty VHD file you need to populate. However, the NT hardware abstraction layer needs to be replaced with one that is appropriate for the new virtual server on which you'll deploy this server. The old HAL won't work since none of the physical hardware will be present.

To deploy the target image to the new virtual machine, use the following command (replace file4 with the name of your server):

C:\Program Files\Microsoft VSMT\p2v\file4\file4_deployvm 

This command starts up the new virtual machine with a PXE boot floppy image, which then boots the virtual server to a point where ADS can deploy an appropriate image. When done, your virtual server will have a HAL consistent with the virtual hardware and will hopefully be configured just like the old physical server.

Post migration

When the image has fininshed deploying, restart the virtual server and make sure the expected services are working. Once it's booted, you should also install the virtual machine additions on the newly created virtual server.

It's not as hard as it sounds

You probably noticed that VSMT is fairly complex and relies on a number of other services. It provides a way for you to migrate legacy or underutilized servers to different hardware and potentially reduce maintenance costs.

Editor's Picks