Consolidation is a highly touted benefit of Microsoft Virtual Server. Being able to merge five or more older servers into one new one saves energy and frees up needed rack space or floor space. What's confusing is how to consolidate in the right way. In order to boost the odds for success, you have to address the nitty-gritty technical details and create a step-by-step plan for before and after the physical migration.
Migrating a computer into Virtual Server is typically done with Microsoft's Virtual Server Migration Toolkit, or VSMT. Microsoft has provided detailed instructions on how to use VSMT, so rather than recapitulate those instructions here, this article will be about the other things you need to do before, during and after a migration.
1. Examine what's being migrated and where it's going.
Before considering a migration, take a look at how the server in question is put to use. An externally accessed server should be re-granted the same access rights to the outside world after it's been migrated. If the physical server's main use is internal, make sure the virtual server will preserve that functionality. For instance, if you're virtualizing a machine that functioned as a catalog server, remember that it will still need to be accessible as such, so keep the old network topology in mind.
If you're combining multiple servers into one box, be mindful of how their combined bandwidth needs might overwhelm the new physical host. You might need to install more than one network adapter to share the load. Also, the physical capture process will occur across the network, so make you have a clear and speedy network path between your virtual server and the machine to be captured.
If you're migrating a multiprocessor server, the migration process will force the new system image to use a single-processor HAL, because Virtual Server does not yet support virtualized multiprocessing. If you have applications running on the migrated server that have been tuned to use multiple processors, you can elect to re-tune them before you migrate if you anticipate problems with leaving them as-is.
Finally, any standing technical problems should be resolved. If CHKDSK returns errors, for instance, or if some other issue presents itself, deal with those before starting the migration. Don't try to solve these issues in the same downtime window as the migration itself; set up separate downtime to deal with them if you have to.
(As a side note, one of the nice features of migrating computers into Virtual Server is that the process is basically non-destructive; it involves only taking the computer offline and imaging it across the network. If something goes wrong, the image can be wiped and redone without affecting the original server. If something goes really wrong with the target servers, the original server can always be put back into operation.)
2. Check the migration requirements.
VSMT has some migration requirements that you may or may not be able to meet. In the machine that is to be moved, WMI must be installed, the network adapter must support PXE 0.99c or better, the computer must have at least 96 MB of physical RAM, and the computer must be able to perform a PXE boot. Most of these requirements should not be difficult to meet, but you should verify them in advance. Don't let them trip you up after you've already staked out your time window to make the migration. You'll also need to have Windows Server 2003 Automated Deployment Services (ADS) running in the migration environment because it will handle part of the migration process.
If the computer being migrated relies on hardware that cannot be emulated (such as hardware keys for certain programs), the migration will not work. The key word here is "relies." A connection to a SAN, for instance, could be restored after the migration was complete, but a hardware dongle generally cannot be reattached to an emulated server.
3. Plan your downtime.
In every single case of migrating a physical server into a virtual machine, the server in question will have to be taken offline for it to be migrated. Downtime should always be planned ahead and set at a time when use of the machine in question would be at a minimum. For an internal server, weekends are usually good; for something accessible from the outside world, pull the access logs and choose a time that will have the least impact on existing users.
The downtime should also be set to a time when there will be minimal network traffic across the segment where you need to do the migration. That way, you'll have the most bandwidth available to you and the migration will take less time.
If you're wondering about the general window of time to allot for the migration, the answer will vary according to the speed of your network and your hardware. As a general rule of thumb, migrating a machine over a switched 100 megabit network will take about one hour for each 7GB of data migrated. Err on the side of caution; plan too much downtime instead of too little.
Note that if you're migrating more than one machine into Virtual Server, you will only be able to migrate one machine at a time with ADS. This is probably for the best, because you want to treat each machine as a separate case with its own downtime window. The last thing you want to do is try to debug migration problems for three machines all at once.
4. Run the migration and make sure all is well.
The migration process itself consists of three steps: capturing the physical machine across the network, using the captured data to create a new virtual machine and then initializing the new virtual machine and cleaning up. During the actual migration, you can watch it happening in real-time in either the ADS administration console or the Virtual Server Administration Web site. Use whichever one you're more comfortable with or run them side-by-side to compare.
After everything is finished, look through the logs generated by both the Virtual Server and ADS consoles to make sure everything went well. Boot the new machine, and then ensure that the OS and its applications are responding as expected. If they aren't, resolve that first before attempting to install the Virtual Machine Additions or other additional applications. If all seems well, you can then remove the captured system image from the ADS store and take the old server offline.
As a final recommendation, keep the old system on hand for at least two weeks while you make sure the migrated version of the server behaves properly. If, for whatever reason, you need to go back to it, it'll still be there.
