IT Expert Voice

Server virtualization saves money and power, but that doesn’t mean you should virtualize everything. Some resources should be left alone.

“Because we can” is a lousy reason to virtualize a server.

Yet in a surprising number of cases that’s what the argument for virtualizing a particular server boils down to. The company has a virtualization initiative under way and that server is just sitting there, so . . .

While the advantages of server virtualization are undeniable, that doesn’t mean it’s a good idea to virtualize every application and every server in the data center. In fact, in some cases, using virtualization is asking for trouble. A “virtualize everything” policy can cause many problems, including degraded performance, support headaches, increased licensing fees, and sudden lack of support from software vendors.

One of the tricks in a successful server virtualization program is to know what you don’t want to virtualize – and why not.

Resources, Not Applications

The “why not” part is important. Many discussions of virtualization candidates deal with particular applications. You’re told, for example that you shouldn’t virtualize SQL databases, or Exchange servers.

Actually, that’s exactly the wrong approach. Such advice, followed blindly, can cost money in lost virtualization opportunities. In fact, SQL databases, Exchange servers, and such are successfully virtualized all the time. Given the right SQL database or Exchange server, that is.

Instead, look at the underlying reasons why some things aren’t good candidates for virtualization. The key issue is resources.

The Tao of Virtualization is that:

• There’s a real computer down there somewhere, and
• Virtualization is not magic.

In other words, each physical server has finite resources, including I/O bandwidth and RAM, and everything still has to fit.

Some applications and servers aren’t good candidates for virtualization because they use excessive resources. It may be that the candidate takes too much of just one resource, such as input/output operations per second (IOPS), or it may need several of them. Big production databases of any variety are a classic example. They tend to eat too many CPU cycles, too much memory, and too many IOPS.

An example of a server that might be limited by a single resource is a web server, which uses most of the available I/O bandwidth. There just aren’t enough resources left over to effectively share the physical server.

The key here is not the kind of application or server; it’s the demand on available resources that defines a poor virtualization candidate. Thus, many databases, web servers, and such are good candidates for virtualization as long as they don’t put too much demand on the physical server’s resources.

The first step in deciding if something is a good candidate for virtualization is to see how much of what resources it uses. This includes peak load as well as average use of the big three: I/O, CPU cycles, and memory. These need to be monitored over a period of time, including any significant events, such as end of quarter. Fortunately, the performance monitoring tools in most data centers easily can log and report this information.

Disaster Recovery

Even if you can’t save money or energy by virtualizing an application or server, you may still want to do so for disaster recovery purposes. A production database may need its own physical computer, but it may be worth virtualizing anyway if it cuts hours off the time needed to get it up and running at a remote site when a hurricane, earthquake, or fire comes calling. However that’s a separate calculus with its own decision tree.

Licensing Issues

Intellectual property barriers to virtualization are becoming lower, but they’re significant enough that they need to be considered.

The most common problem is that the software’s license doesn’t allow virtualization. This may be because the vendor has determined the software won’t operate properly in a virtualized environment. More commonly, these days, the vendor isn’t sure how well the application runs in such an environment, and just doesn’t want to take the chance.

Whether the software works or not, it is not a good idea to use it on a virtualized system contrary to the vendor’s license agreement. If nothing else, it will probably cut you off from support if something does go wrong.

Specialized Hardware

Another problem, especially outside the confines of the IT department, are systems with specialized hardware such as controllers. These often include unexpected hooks into the hardware, and they may not virtualize well at all. The vendor should be able to tell you about support under virtualization, and you should follow their advice.

A combination IP/specialized hardware problem is the dongles that some software vendors, especially of CAD and graphics programs, still use for copy protection. These things are a pain in general, but they are a particular problem when you want to virtualize the application. Again, check with the vendor about compatibility with virtualization or the availability of a workaround.

Still A Win

Server and application virtualization is still a win in most cases. You just need to make sure you understand the limits and pick your virtualization cases carefully. Check the resources each application needs and look for other issues before you decide to virtualize.

Related Information From Dell.com: A Smarter Path to Virtualization