id you ever notice how IT trends tend to be cyclical, mirroring trends in clothing styles and television shows? Women are wearing bell-bottoms again and we’re watching a lot of cop shows these days, just like back in the 1970s.In IT, we are running virtual machines (VMs) on Intel platforms just as we were doing 20 years ago on mainframes.

But today, the virtualization movement is much larger because we can virtualize on industry-standard x86 platforms, which form the majority of desktop, laptop, and server shipments and enable much cheaper virtualizations than mainframe systems did. We can run multiple operating systems on a single physical system and share the underlying hardware resources, which not only saves money but also simplifies system management.

And let’s not discount the portability of today’s VMs. A VM running on a Dell server can be moved to an IBM server and then over to an HP server, all without making any changes to the VM. That is a giant step forward from where we were 30 years ago.

The company I worked for decided to check out virtualization to reduce costs. We chose VMware because it is the market leader and its ESX server product gave great performance for the cost. Our team consisted of an architect and three engineers. We had help from other groups as needed, but that was the core group that got it implemented. We spent several months training and using VMware ESX Server before implementing it enterprise wide. Today, we have dozens of hosts running hundreds of VMs.

Comparing the differences between each product and determining which is best is beyond the scope of this article (See Sidebar. Major Virtual Infrastructure Players). Suffice it to say, you can pick the best product yet still fail miserably in your virtualization project if you do not plan well. Let’s talk now about how to be successful implementing a virtualization product at your company.

A Step-by-Step Process

When the company I worked for decided to adopt a virtualization solution, they chose VMware ESX Server for a multitude of reasons. We wanted to go with the market leader and use the product that would allow the greatest use of virtualization, while maintaining the lowest possible costs and minimizing hardware. We found that the main players for us were VMware and Microsoft, as the others were way too expensive or didn’t support Microsoft as a VM. Comparing the number of VMs against the total ROI and TCO, VMware ESX was the best choice.

We spent the first few months learning about the product, completing extensive research on how to set up and configure it, and determining which servers would be virtual and which physical servers to migrate to a virtual environment. We finally went live with our implementation after five months.

We started with the lowest-risk servers?our test servers?in case there was an issue. When all went well with the test servers, we moved on to disaster recovery and staging servers. Finally, we went after the CPUs with the lowest utilization, migrating them to a virtual environment with VMware’s P2V Assistant. VMware P2V is a migration tool that transforms an image of an existing physical system into a VMware virtual machine.

Note: In addition to VMware’s P2V tool, PlateSpin has a product that works nicely in this area.

At first, we fielded a lot of questions from our developers and users about VMware and how we were using it. Surprisingly, the biggest doubters were members of our IT department. We had to prove to them that virtualization was a good strategy for the datacenter, both in terms of productivity and cost savings. Today, the same people who questioned “going virtual” are the ones who complain when they can’t virtualize their projects.

Two years later, we have hundreds of virtual machines running on several dozen VMware ESX Servers. Virtualization has been invaluable in our disaster recovery strategy, because we can swap out a failed server with a spare we keep just for this purpose, reboot the virtual machines onto the new machine, and be up and running in about 45 minutes.

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 easy?it 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 first?specifically, 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.

Issues and Resolutions

As you well know, the server eventually will fail, if for no other reason than a system board failure. To help minimize this impact, do not group all virtual machines from the same group together, nor group all production or all test servers together. We decided that no more than 60 percent of the virtual machines on a physical server would be production servers; we use the rest of the capacity for development, staging, test, and disaster recovery virtual machines. This way, if a server goes down, it is easy to prioritize which virtual machines need to be recovered in the event of a serious disk failure. Or if the system board has an issue, an entire group of virtual machines won’t go down with it. Rather, just a few systems from each of several groups are affected.

When you are deciding what else to migrate to a virtual environment, stop and review the documentation. Is it current, or have you made some changes? If so, update it first and then ensure that various members of your team have been cross-trained. Planning like this is where you can make yourself (and your virtualization project) really valuable to your managers and executive team.

As your virtual infrastructure grows, expect growing pains that test the manageability of the new environment. If the product you are using for virtualization does not have strong management capabilities, you’ll end up spending a lot of time performing duties that otherwise could have been automated.

As an example, suppose you have more than 50 virtual machines running on several servers. How do you find out (easily and quickly) where VM “X” is? What if you have 300+ virtual machines? What if you have 1,000? How do you shut down all of the virtual machines, or automatically start them when you need to reboot the physical server? With VMware’s VirtualCenter product, you can easily do all this and more. If a product like VirtualCenter is not available, you will need to consider some type of scripting, such as Perl, to automate some of these functions. Otherwise, they will eat up your time and you will not gain all the efficiencies and cost savings that virtualization promises. For example, if you need to perform an upgrade of the host server for the virtualization product you choose, you then generally need to upgrade a software component running in each VM as well. Since it takes one minute to log on to a system, doing this manually is very time consuming.

Planning Is Key

Virtualization is here to stay. According to everything I have read, companies that do not use virtualization technology will have higher costs in not only acquiring new systems but also in maintaining existing (legacy) systems. Based on what I have seen at different engagements, for every 1,000 servers a company has, it stands to save a minimum of $750,000 by using virtualization.

Which product should you pick? That depends on what you are looking to do. What works for one company will not necessarily be right for your company. Not that the product can not do what you need, but if you want to virtualize a number of test servers and are really sensitive to upfront costs, then you need to look for a less expensive solution.

With planning and some training, your company can easily amass significant savings. Plan well so you can execute flawlessly. If you succeed, your group will be stars to management. And when you look back after your first year and see the money you’ve saved, how about throwing some my way? : )