Servers

Five tips for deciding whether to virtualize a server

Not all servers are suited for virtualization. Be sure you consider these possible deal-killers before you try to virtualize a particular server.

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.

About

Brien Posey is a seven-time Microsoft MVP. He has written thousands of articles and written or contributed to dozens of books on a variety of IT subjects.

8 comments
javalexlan
javalexlan

I have to deal with several "servers" for specific applications that actually are just workstations, This helped me to justify the acquisition of a proper server and virtualize all these pseudo-servers, gaining a bit of "peace of mind" in the process. Fortunately there were no major requirements and only one of those required a USB dongle for a particular app, so it was well managed with our solution.

markamis
markamis

We have been runniing (working with the vendor) a virtual Linux box running a pharmacy app that uses Oracle with great success for the last 2 years. However, we would not have done it without the vendor working with us. As a side note, it was the first time for them to run this large app on a virtual box, but testing together went well. There have been no performance problems and the app is used at multiple remote pharmacies on our WAN.

WayneAndersen
WayneAndersen

If it is an Active Directory Domain Controller, make sure you have at least one Domain Controller that is on a physical box. If it is a heavy duty SQL server, it probably won't work well on a virtual machine.

Colinza
Colinza

Risk management is big business and vital in large mission critical environments. If you are running Joe???s corner auto spares you might consider the gamble but if you???re a large Stock exchange you do not want that blunder on your resume should that non standard configuration violate your support agreement. Believe me, no matter the problem, a vendor will use that as an excuse ??? and rightly so. If the app is that important then apply pressure on the vendor to certify the configuration or obtain some agreement with them but don???t just do it. It???s all part of proactive service management ??? something that eludes many tech focused minds.

Tommy Orange
Tommy Orange

While there are a few good points on determining if the software will run or not ??? I would have to disagree with the hardware dongle and support policy points. There are many low cost options for running USB over IP and we have used this scenario in our LIVE environment for many years. Also the support policy point is flawed ??? there are numerous software vendors who haven???t spent the time and money to certify their solutions on a virtual environment and therefore don???t officially support it. We have this scenario in a few of our key business systems ??? once again ??? all running in a virtual environment without incident. The benefits of a virtualized server environment ??? at least for most folks ??? heavily outweigh the risks of not going down that path. One should still conduct their due diligence but risk appetite needs to be considered when migrating to a virtual environment as everything isn???t black and white.

mjh2901
mjh2901

We have 3 options for servers. 1- Virtualize 2- Mac Mini 3- Big Stand Alone Server 90 percent is 1 a couple (all have hardware dongles) where moved to mac minis running Windows Server 2003 or 2008 to save energy and space plus old software does not really need much power the final and only big stand alone server... Exchange 2007.

jmarkovic32
jmarkovic32

...and tell the vendor that it's running on a physical box (technically it is). Most of them would be none the wiser.

Editor's Picks