As time goes by, the relative cost of available CPU, RAM, and storage capacity continues to drop. As a result, many PC and server users have more computing horsepower than they can fully utilize. For system builders, this presents an opportunity to help customers make more complete use of this idle hardware. One solution that can help is virtualization technology.

By consolidating servers with virtualization, system builders can help their customers deploy applications more efficiently, using less hardware. System builders can set up a Windows server and a Linux server on the same physical machine, for instance, and allocate resources between them as necessary. In this way, virtualized servers can save customers a lot of money, and system builders can take credit for streamlining their customers' IT infrastructure. This should win more business opportunities in the long run. It should also reduce potential service calls by putting less hardware into the field to run the same applications.

Microsoft, among others, offers a product that addresses this need: Virtual Server 2005 R2 Standard Edition. In this Recipe, I'll discuss the ins and outs of server virtualization, and explain how to install Microsoft's Virtual Server 2005 R2 Standard Edition software to create a virtual server.

The proliferation of 64-bit computing hardware and software means system builders can now install extremely high-performance systems. For example, today's servers can address more than 4 GB of RAM. CPU clock speeds now approach 4 GHz, with multiple cores on each chip able to tackle additional computing demands. Storage capacity has skyrocketed, too: Terabyte storage arrays are now within the reach of system builders who serve the small and medium business (SMB) market. Until quite recently, these performance levels were limited to only the largest of enterprises. But no more.

Another phenomenon is contributing to the under-utilization of available hardware, too: Today's Commercial Off-The-Shelf (COTS) software is typically compiled for maximum compatibility, instead of for performance and resource utilization. In fact, these applications are typically optimized for use on a single machine with one or two CPUs and up to about 2 GB of RAM. But if your systems have more power than that, they're probably not being fully utilized by the software.

One way to combat this limitation is to make each application think it is running on just such a machine. For example, let's assume you have two key applications on the software side, and one server with two processors and 4 GB of RAM on the hardware. For this setup, you could create two virtual machines, one for each application. This way, the available hardware resources would be utilized by the software much more efficiently.

Virtual Pitfalls

But there are pitfalls to creating virtual machines. One is the added temptation to create more and more virtual machines. Also, the more virtual machines you have on one physical machine, the more problems you have with security vulnerabilities and time consumed with management duties. A hardware failure now affects not just one physical machine, but also several virtual ones.

Another pitfall: While CPU clock cycles, memory capacity, and storage are available in prolific quantity, I/O bottlenecks still exist. In fact, bottlenecks can be exacerbated if you create too many virtual machines on one physical machine. The risk is that all the virtual machines will attempt to access memory or storage simultaneously. If this happens, virtualization can actually reduce the server's performance.

There are other issues, too, most notably reliability, serviceability, and availability. As the number of virtual machines increases, the importance of these issues for the physical machine also increase, sometimes dramatically. For example, any situation that requires a re-boot will now affect multiple machines at once -- all the virtual machines, plus the physical machine. Also, any single hardware failure will now affect multiple servers, for the same reason.

Similar concerns apply to virtual machines from the standpoint of networking and security. Any time you connect a machine to a network, you have just created a security risk. Whether this risk is acceptable depends on the system owner and/or sys admin. But a security breach at one point could leave multiple servers vulnerable.

As a result, system builders must be careful when employing virtualization technology with servers. You need to strike a balance between financial savings on the one hand, and budget needed to manage, operate, and secure the virtualized servers on the other.