Where to Begin
The best way to get any virtualization method implemented is to first understand exactly what you are trying to do. The two most common reasons for virtualizing are saving money and addressing capacity issues such as limited rack space.
No matter the issue, you can easily make a case for purchasing quad-processor servers, and perhaps even eight-way servers, because the cost of these large machines is substantially lower today than it was a few years ago. After all, the lowest-cost upfront method to begin your virtualization project is to use internal storage. However, in VMware's case, this would rule out the use of VMware's VMotion, which is a method of migrating virtual machines from one physical server to another without an outage. VMotion requires a storage-attached network (SAN).
Once you choose a hardware platform and verify that all the parts are on the software manufacturer's hardware compatibility list, the next process is to get trained on the product.
The first step is to create a lab setup with a minimum of two physical machines, enough disk space for four to eight virtual machines, and enough server resources (RAM, NIC, CPU, and disk I/O) to handle the virtual machines' activities. Then install and configure the virtualization software. If you are using HP or IBM servers, you will need to do some hardware tuning.
Once you have installed and properly configured the software, you need to become familiar with the product. No matter which product you use, the vendors all offer training at a fairly nominal cost. For support reasons, maintaining an excellent relationship with your virtualization product vendor is also critical. One bad experience can lead to virtualization being delayed or potentially not even being adopted.
On to the Fun Stuff
Once you are familiar with the product, create a number of virtual machines to learn how the process works. Familiarize yourself with how the VMs share the physical servers' (hosts') resources and what, if any, impact changing parameters or adding new virtual machines has on the other virtual machines.
You also should create good documentation explaining how to set it all back up if (or when) an issue arises. As an example, most companies that use VMware ESX Server do not back up the host server because installing and configuring it is very easyit takes only five to seven minutes. However, backing up the virtual machines themselves is critical, as is backing up each VM's configuration files.
When you start virtualizing, go after the least critical servers firstspecifically, the ones that won't create a huge problem if they fail and the ones that use minimal CPU. Typically, these are development or test servers. As an example, my company first used a planning tool to gather metrics on CPU, network, RAM, and disk I/O over the course of a month. We then focused our first efforts on the physical servers that used less than 20 percent CPU, using VMware's P2V product to move them from physical machines to VMs.
Make sure your own migration process, regardless of which tool you use, does not make any changes to the physical server's hard drive, as changes can cause issues. VMware's P2V tool boots to a CD-ROM and writes no data to the physical server's hard drive at all. This way, if you have to turn the VM off and fail back to the physical server, it most likely will work without problems.
Once you have the lower-end servers running in a virtual environment, you can tackle the higher-end servers, those that have 20 to 40 percent CPU usage. Give careful consideration to avoid overloading a system. It is better to mix high CPU/low disk I/O/low RAM usage virtual machines with virtual machines that are low CPU/high RAM usage than to have all of the same type on the same physical server.