Even though server virtualization is all the rage these days, some servers simply aren’t good candidates for virtualization. Before you virtualize a server, you need to think about several things. Here are a few tips that will help you determine whether it makes sense to virtualize a physical server.
1: Take a hardware inventory
If you’re thinking about virtualizing one of your physical servers, I recommend that you begin by performing a hardware inventory of the server. You need to find out up front whether the server has any specialized hardware that can’t be replicated in the virtual world.
Here’s a classic example of this: Many years ago, some software publishers used hardware dongles as copy-protection devices. In most cases, these doubles plugged into parallel ports, which do not even exist on modern servers. If you have a server running a legacy application that depends on such a copy-protection device, you probably won’t be able to virtualize that server.
The same thing goes for servers that are running applications that require USB devices. Most virtualization platforms will not allow virtual machines to utilize USB devices, which would be a big problem for an application that depends on one.
2. Take a software inventory
You should also take a full software inventory of the server before attempting to virtualize it. In a virtualized environment, all the virtual servers run on a host server. This host server has a finite pool of hardware resources that must be shared among all the virtual machines that are running on the server as well as by the host operating system.
That being the case, you need to know what software is present on the server so that you can determine what system resources that software requires. Remember, an application’s minimum system requirements do not change just because the application is suddenly running on virtual hardware. You still have to provide the server with the same hardware resources it would require if it were running on a physical box.
3. Benchmark the system’s performance
If you are reasonably sure that you’re going to be able to virtualize the server in question, you need to benchmark the system’s performance. After it has been virtualized, the users will be expecting the server to perform at least as well as it does now. The only way you can objectively compare the server’s post-virtualization performance against the performance that was being delivered when the server was running on a dedicated physical box is to use the Performance Monitor to benchmark the system’s performance both before and after the server has been virtualized. It’s also a good idea to avoid over-allocating resources on the host server so that you can allocate more resources to a virtual server if its performance comes up short.
4. Check the support policy
Before you virtualize a server, check the support policy for all the software that is running on the server. Some software publishers do not support running certain applications on virtual hardware.
Microsoft Exchange is one example of this. Microsoft does not support running the Unified Messaging role in Exchange Server 2007 or Exchange Server 2010 on a virtual server. It doesn’t support running Exchange Server 2003 on virtual hardware, either. I have to admit that I have run Exchange Server 2003 and the Exchange Server 2007 Unified Messaging role on a virtual server in a lab environment, and that seems to work fine. Even so, I would never do this in a production environment because you never want to run a configuration on a production server that puts the server into an unsupported state.
5. Perform a trial virtualization
Finally, I recommend performing a trial virtualization. Make a full backup of the server you’re planning to virtualize and restore the backup to a host server that’s running in an isolated lab environment. That way, you can get a feel for any issues you may encounter when you virtualize the server for real.
Although setting up such a lab environment sounds simple, you may also have to perform a trial virtualization of some of your other servers. For example, you might need a domain controller and a DNS server in your lab environment before you can even test whether the server you’re thinking about virtualizing functions properly in a virtual server environment.