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? : )