We all have plenty of reasons to procrastinate, and many of us had a good reason for prolonging the migration process from Windows NT—application incompatibility. If my NT applications can't reliably run on a Windows Server 2003 or Windows 2000 system, then I'm better off addressing the known concerns of running these programs on NT and planning for periodic reboots than tackling new problems associated with a new OS. Although some companies can replace or upgrade legacy applications to facilitate a migration, other organizations don't have that luxury and must maintain legacy OSs to support needed applications.
Many administrators discover that the answer to the migration dilemma is to use virtual machine (VM) technology. VMs let you run multiple OSs on the same physical system at the same time. In fact, neither computers on the network nor applications can distinguish a VM from a physical machine. Before you can begin to use VMs, you need to determine which application you'll use to provide the management overhead for each VM. VMware Workstation (or VMware GSX Server or VMware ESX Server) and Microsoft Virtual Server are two possibilities. These applications let you create a VM, complete with virtual hard disks (IDE or SCSI), virtual RAM, and other virtual resources such as network interfaces that let you connect to your physical network. After you define the machine's virtual hardware, you can power it on and install the OS. If you're interested in using the VMware products, be sure to check out "VMware GSX Server 2.5," July 2003, http://www.winnetmag.com, InstantDoc ID 39182, and "VMware Workstation 2.0," February 2001, InstantDoc ID 16446. I've used Virtual Server in the migration process, so let's begin by examining the product's origins and features.
New Kid on the Block
Virtual Server is still in beta and rapidly changing, so I can't go into too much detail about operating the software. However, Windows & .NET Magazine will continue to follow the software as it develops.
Virtual Server was born when Microsoft acquired the Connectix Virtual Server line of products. Unlike VMware's products, Virtual Server is designed to be hosted exclusively by Windows OSs (specifically, Win2K or later running Microsoft IIS). Because Virtual Server VMs can fully integrate with the host OS, they don't require third-party graphics or network drivers. Instead, virtual hardware devices emulate hardware that's natively Plug and Play (PnP) with Windows OSs. In addition to this PnP integration, Virtual Server offers performance counters for monitoring VMs and supports a couple of features that VMware users have come to know and love, including support for legacy OSs and script-based management.
System Monitor counters on the host system for monitoring VMs. In addition to OS support, when you install Virtual Server, the software adds System Monitor counters to the host system. The counters let you collect performance data on all your VMs from the host system. Figure 1 shows a sample collection of VM data that I collected using System Monitor.
Support for running legacy OSs (i.e., NT, Win2K, OS/2). Virtual Server's legacy OS support gives you an easy path for eliminating some of the antiquated systems that you maintain for running certain applications. I recently worked with an organization that maintains a server running NT to support one specific application. That company could scrap the NT server and move its contents to a VM.
Script-based management. Another valuable feature of Virtual Server is its integration with scripting tools. In fact, the product ships with several sample scripts to get you started, including a script called FailOver.vbs that can monitor the state of a running production VM and automatically fail over to a backup VM if the first VM stops responding. One other valuable script called DuplicateVM.js that ships with Virtual Server lets you clone VMs—this script even works with live VMs. DuplicateVM.js is ideal for creating backup copies of your VMs so that if a virtual server becomes corrupted or crashes, recovery is as simple as starting the backup version of the server and restoring applications or file data from backup.
Now that you know a little bit about Virtual Server's features, you need to know how to put it to work and how to move your legacy applications from the physical world to the virtual world. In the remainder of this article, I walk you through my favorite methodology for making this transition. Let's start by setting up and configuring the host server, then configuring virtual representations of your production NT servers.
Configuring the Host Server
You need to ensure that the host system for the VM is running Win2K Service Pack 3 (SP3) or later and IIS. The latter is required to send commands to the Virtual Server service because Virtual Server doesn't contain a standalone application for this task (as of beta 1). If you don't want to run IIS on the host system, you can configure the Virtual Server Web site on an alternative server (the online Help file contains information explaining how to do this). If you absolutely can't run IIS, Microsoft recommends using Microsoft Virtual PC instead of Virtual Server to control your VMs (Virtual PC isn't as robust as Virtual Server, but it doesn't require IIS).
Remember, VMs consume resources just as physical servers do, so make sure you have enough RAM and hard disk resources on the host server to accommodate the number of VMs that you plan to run concurrently on the host. For example, if you plan to allocate 128MB of virtual RAM for each of three NT server VMs, you'll need to install 384MB of RAM in addition to the amount of memory that the host OS and its running applications require. Also, be sure to allocate enough disk space for each VM's virtual hard disks. You don't need to create separate partitions for the hard disks because the virtual hard disks are stored in files with .vhd file extensions.
After you've set aside enough resources for the VMs, you need to determine how to network them. You can either have them share the host computer's network adapter and directly connect to the production network, or you can configure them to use a virtual network that connects only to the host system. I prefer the latter approach primarily because it isolates the VMs from the physical systems on the production network. Also, creating a virtual network connection eliminates NetBIOS conflict errors during the migration process and lets you fully test and configure the VMs without affecting the physical production NT servers.
To set up a virtual network, you need to open the Control Panel Add/Remove Hardware applet on the host system to install the Microsoft Loopback Adapter. After you install the adapter, edit its TCP/IP settings to assign the first IP address to the adapter on a unique network, such as 10.1.0.1/24. When you install VMs on the host server, you can configure their network interfaces to use other IP addresses on the same virtual subnet.
Of course, a virtual network that can only be seen by the VM host is pointless if users can't access the virtual NT server. To facilitate user access while keeping all VMs on their own private network, I configure Routing and Remote Access on the host system to act as a network router. You can use the Microsoft Management Console (MMC) Routing and Remote Access Service snap-in to quickly set up this service by running the configuration wizard that appears after you first attempt to configure the service. To let any administrator access the virtual network and the live VMs, you can use the Route Add command to add static routes to the administrators' systems. For example, to access the virtual network 10.1.0.0/24 attached to a host system with an IP address of 172.16.12.34, you would run the command
route add p 10.1.0.0 mask 255.255.255.0 172.16.12.34
When you're ready to permanently transition all your VMs into production as replacements for the physical NT servers, you would just need to update the routing tables of your production routers, then modify each VM's A host records on the production DNS server.
If you don't want to go down the routing path, you can always configure your VMs' network interfaces to connect to one of the host system's physical network interfaces. This configuration would let the VMs connect directly to the production network and only require that their virtual network interfaces have a unique production IP address. If you take this approach, remember to isolate your VM from the production server that it's replacing so that you don't get NetBIOS errors, which would occur if the identical systems were able to see each other on the same physical network segment.
Adding VMs
After you've planned how much disk space and RAM to use for the VMs and configured the virtual networking on the host system, you can install the Virtual Server application by downloading and running the executable file, then setting up the VMs. To add VMs, you need to access the Virtual Server Master Status page—go to Start, Programs, Microsoft Virtual Server, then click the Master Status shortcut or point your Microsoft Internet Explorer (IE) 5.5 or later Web browser to http://host server name:1024/virtualserver/vswebapp/vswebapp.exe to access the Web management GUI, as Figure 2 shows.
After you access the Master Status page, you need to configure a virtual network for the virtual server to use. From the Tools menu, click Virtual Network Manager, then select Create Virtual Network. You'll need to name the virtual network and select the network from the Host Network Adapter drop-down menu to connect to the Microsoft Loopback Adapter on the host system.
You can now create a new VM. From the Tools menu, click Add Virtual Machine and allocate RAM and a virtual hard disk to the new VM. For its virtual network interface, in the Ethernet NIC field, select the virtual network that you just created. Then, click Create Virtual Machine to create the VM.
After you configure the new VM, you just need to turn it on—click the Master Status link, then put the cursor over the name of your newly created VM and select Power On to start the new VM. To control the live VM, click the VM's thumbnail on the Master Status page. To simulate the Ctrl+Alt+Del keystroke sequence, press the right Alt key, then press the Del key. To exit the VM, press the right Alt key on your keyboard (you can change this default key, if desired).
At this point, you need to install an OS for the VM, just as you would need to do for any physical system. During the OS installation, make sure you configure the network interface to use an IP address on the VM host's virtual network. For the first VM on the virtual network, I assigned it an IP address of 10.1.0.2/24 and listed its default gateway as 10.1.0.1. The 10.1.0.1 address was assigned to the Microsoft Loopback Adapter, which will act as the gateway for all VMs on the 10.1.0.0/24 network. Because my NT 4.0 VM was replacing a physical production NT server called BSOD, I assigned the name BSOD to the VM.
After you install a base OS, you might want to consider using Sysprep on the system, then running the DuplicateVM.js script to create a new base image VM. You can then use the cloned sysprepped VM as a baseline for any additional virtual NT servers that you need to set up.
Migrating Applications
Now that the OS is running, you can move on to migrating the applications. Note that we haven't yet joined the VM to the production domain—doing so while the production server is still online would lock out the production server's computer account because joining a computer to a domain automatically regenerates a new computer account password for that system object. As a result, the production system's computer account password would no longer match the password stored on the DCs. This mismatch would cause authentication between the production system and DCs to fail until the production system is rejoined to the domain, which in turn would lock out the VM. To migrate an application, I prefer to perform a clean installation of the application on the new VM. Following the installation, you can then copy any data saved by the application onto one of the VM's hard disks. If the application data is locked, you can alternatively use backup software to back up the application data on the production server, then restore the data to the VM.
After you transfer the application and data to the new VM, you can test the VM to ensure that it performs as expected. When you're satisfied that everything is working properly, you can join the VM to the domain, update your DNS records, and ensure that all clients can successfully route to the VM. At this point, your virtual transition is finished. You can now use the DuplicateVM.js script to create and store a backup copy of the VM. Then, if a system crash occurs, you can just start the backup VM and restore any recently backed up application data. (For more information about backing up files to a VM, see the sidebar "Integration with Backup and Recovery.")
Keep in mind, however, that you can run into problems when working with two instances of the same virtual system. For example, if a domain controller (DC) changes the computer account password for one version of the VM, you'll have to manually rejoin the backup VM to the domain. To prevent the periodic reset of your VMs' computer account passwords, open a registry editor on each VM, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey, and change the DisablePasswordChange entry value to 1.
Migration Made Easy
If you simply want to clone a production system to a VM, you can use the Physical to Virtual Wizard to do so. The wizard will let you clone a physical system to a VM and test it as a VM during the migration process, removing any negative effects on production. When you're satisfied with the performance of the VM, you can decommission the production server. Another excellent use for the Physical to Virtual Wizard is to clone NT servers before you upgrade them. This way, if a server crashes during the upgrade process, you can bring its cloned VM online as a temporary replacement until you repair the physical server.
Microsoft is making sure that the Physical to Virtual Wizard solution successfully clones Microsoft applications. However, you'll want to carefully evaluate other cloned applications running on the new virtual server before you remove the production system.
Microsoft also plans to include a Virtual to Physical Wizard and a Virtual to Virtual Wizard in Virtual Server. The Virtual to Physical Wizard will be ideal for testing a new server before you place it on a physical production server, and the Virtual to Virtual Wizard will let you easily clone VMs. For example, you'll be able to set up a default VM, run Sysprep, then use the Virtual to Virtual Wizard to copy the VM to a new VM and have a clean virtual OS within minutes.
Beyond Migration
Although Virtual Server is well suited for consolidating NT systems on your network to multiple VMs running on one system, VM technology also presents several other ways to manage systems on your network that previously weren't possible. For example, you can
- configure virtual SCSI disks to support a virtual server cluster running on one physical system (which is great for performing tests, demos, and training).
- configure a VM's hard disks to use the undo drives feature so that the VM discards changes when you power it off—this feature opens up countless testing, training, and e-learning possibilities.
- configure VMs to provide a new way to manage select production Windows 2003, Win2K, Linux, and NetWare servers. Keep in mind that running an OS on top of another OS can affect performance. When planning to consolidate VMs onto one physical host, remember to perform thorough load testing so that you aren't surprised when you place the VM into production.
- have a means to reliably recover Windows OSs to different hardware in the event of a disaster.
If you've done even one disaster-recovery rebuild of a Win2K server to a new system with different hardware, you know how painful it can be. Because VMs emulate hardware, they essentially eliminate hardware differences as a consideration when you're moving an OS and applications from one virtual host to another. If a VM crashes or if a VM's host system fails, you can restore a backup of the VM's virtual hard disks and configuration files to a different server without any complications. This flexibility also comes in handy when you're working with mail servers. If a mail server VM fails, you can quickly bring up a cloned replica of the original VM, which will at a minimum provide users with access to their mailboxes. If your backup software supports message-level recovery, you could then simply restore backed up email messages in the background while still giving users the ability to send and receive new messages. Total mail server downtime, with the use of VM technology, could be limited to a few minutes, as opposed to hours or days.
Easing the migration of your legacy applications is just the start. Although VMs and Virtual Server come with a learning curve, the advantages of these new technologies will keep them around well into the foreseeable future. Virtual Server is expected to hit the shelves in fourth quarter 2003. Stay tuned as these new technologies continue to develop.
