Virtual Servers Vs Physical Servers

I am trying to get the pros and cons of usings a virtual server environment(vmware) vs are current physical server setup.  currrenlty we run about 14 servers in our data center and it seems these days that all the software we buy requires its own server.  i am looking for both pros and cons of have a virtual server setup over a physical server setup. points will be giving to all who provide this info. Thanks
Who is Participating?
za_mkhConnect With a Mentor Commented:
Nearly every piece of software you mention, except for BackupExec (which we plan to get rid off to replace with Veeams Backup Solution) ... we now run in a virtual environment. We have AD, Exchange, SQL, Oracle, Siebel servers running in VMs.
Yes, with Virtualization all your eggs are in one basket because if a host server goes down, you lose all the virtual machines running on it. But if you have vCenter, with DRS/HA/FT/DPM enabled you can run at nearly a 99% uptime.
Currently, we are still in the process of moving all our physical servers to our virtual environment, but we are currently running 68 servers (including those mentioned above) across 5 physical servers. Think about how much kit we have turned off! They still have enough capacity to host more. We keep at least 3 additional physical ESX  as spare (DPM will start them up if needed). As to why virtualisation with vCenter is the way you should go, let me give you an example. In December while we were trying to resolve some configuration issues on our ESX infrastructure, I had to power down the ESX servers to run some updates, etc ... I did this all during production hours while the systems were being used. So in total I effected 150 vMotions and around 10 Storage vMotions (moving data from one SAN location to another) while the Virtual Servers were all running - NOBODY was even aware that all these changes were occuring!
That is why you want a Virtual Infrastructure with a resilient SAN ... it makes your life very easy!
Also like mentioned above .. it becomes easy to provision new servers. It takes me about 15 minutes to bring up a new Windows Server with data storage as requested - thanks to Virtual Machine Templates.
The only thing to be mindful of is the fact that it is expensive (or seems expensive) but the ROI will be immense and that you potentially could have single points of failure e.g. Server failure or SAN failure. You need to ensure you are resilent for nearly everything if possible.
- Pros -

Minimized Hardware Costs
Lower Maintenance Costs
Lower Power Costs
Leverage Hardware to fullest extent
Snapshot / Instant Recovery
Well Documented
Ease of Backup
Variety of Virtualization Attack Methods

- Cons -

Creating more failure points - IE If physical server goes down it takes VMs with it
Physical Servers will require a little more processing power to handle a lot of hosts
Drive Space - One of your biggest limitations will be the speed of the disks you are accessing.

Overall, the benefits of moving to a virtual environment really outweigh the cons. One of the biggest benefits we realize where I work is that, since everything is virtual, it is very simple for us to create a development / test instance. We just copy the images, import the machine, change the address, DNS name etc, and you have a working instance as of last backup.
please describe what application you are talking about:
IMHO: High DISK I/O applications should not be virtualized i.e. database servers, possibly exchange servers.

Searching through EE for virtualization, you will find this issue discussed in great detail.

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

nelslarsonAuthor Commented:

BES could since it ties in into exchange as the back end.
websense could web filtering but there seems to be issues because of the memory usage
Desktop Authority is
Symantec EPP with an SQL backend could be, using the built-in sep db might not be so good.

Check the vendor sites for the various application you are considering to see whether they support virtualization and the type i.e. vmware, hyper-v,xen, etc.

The other consideration is the load distributioni.e. you do not want to place two applications that are heavy network/memory users on the same physical server.
I.e. you have 14 servers and would like to go down to 5?
You need to distribute the VM application among the physical servers such that no one physical server is maxing out on memory/cpu.
If all your systems are dual processor multi core with 4GB of memory and their normal/peak usage is 10%/30%, using the same hardware could be possible for two applications (no DB no Exchange).

If you have a baseline of the current applications/physical servers. You could use those to virtualizing certain applications to one physical server.

I've been an MCSE for 11 years now supporting all kinds of environments and I can tell you this - the only downside or CON to using VMware over a traditional physical environment is performance, period, and cost too if you plan on moving toward shared SAN.. but in the end the shared SAN will pay for itself and studies show VMware investments are returned in an average of 7 months time, but the ROI for a smaller environment with only 14 servers will take much longer.. and performance is only degragated by about 7 % all in all, but if you start building ESX servers with too many high I/O applications running be prepared for a higher hit.. Thing is, the slight degradation is hardly noticeable most of the time and well worth it!  I've been a VCP for 3 years now and have made VMware my career focus over the past 5 years, the flexibility you gain is par none.. VMware will completely change your perspective and in large part your life as an IT admin about how to run an IT shop and provide application services to your users.  The difference is so powerful it is like being reborn.  If anyone disagrees with me on this speak out and I will help you figure out what your doing wrong.. hahaha
Final recommendation, if you move to VMware, which I recommend, here's what you should do:

1)  you only have 14 servers now, so you don't need much, start with 2 ESX hosts connected to a low cost iSCSI san with vSphere essentials licensing, you can get fitted into all this for under 30k, I've provided quotes for small environments on many occassions.. 3k for vSPhere essentials with HA, 12 - 15k for HP iSCSI SAN with disks, and an additional 10k for the 2 servers.. That should cover it, but the price will vary depending on how much SAN disk you need, that is where your biggest cost variant will be.. and keep in mind that you can't upgrade out of vSphere essentials to a version that has vmotion capability, you will only have HA.. to get started with Vmotion capability you have to cough up a lot more money to VMware and that will bring you up over 30k no matter what.  

Next, carefully review all documentation before you start hacking, download the best practice white papers from VMware and learn how to properly build and configure your environment before you dig in.  This is the one mistake people make, they don't do their homework.  and be sure to learn about how to engineer you SAN array for use with VMware, again, its in the documentation and white papers.. Vmware environments are shared and the arrays used for them require a full shelf of spindles to handle the I/O.  if you only have 2 TB of space as a total requirement then don't get there by building a RAID 5 array on 3 1TB drives, build an array using as many disks as possible, say 12 300GB drives or something.. This way you will have plently of spindles to handle the growth of your VMware environment.

As for exchange and other high I/O apps with databases, follow the partition alignment white paper to learn how to properly configure your virtual disks to handle this, its easy!  

Most everything you need to be successful and understand VMware is here:


Note - I didn't bother to mention the basic VMware admin and server config documents because they are obvious and you know you have to look at them first as well since they have the requirements, install procedures, and admin procedures.. the ones I listed are the ones most admins leave out that in the end make you a top notch VMware engineer and admin.
You've stated most clearly that the benefit of Virtualization is highly dependent on the scale/number of existing servers.
The ROI depends on what the firm does. IT setup for an internal set of applications is more of an insurance policy than an investment for a return.

nelslarsonAuthor Commented:
we are are small state agency that would need to have some sort of failover
I think having 14 servers you can achieve redundancy with the existing infrastructure.
I.e. have two servers that have BES setup, Desktop Authority, Symantec SEP with MS SQL backend and possibly document imaging.
A nother pair of servers could be for Symantec spamfiltering and websense (i.e. one is running and one is just installed or just the configuration files are there.  If the first fails, the service needs to be started or the application installed and then started depending on the licensing model websense uses. )
backupexec could be setup on two servers if licensing permits and their schedule could be that each works every other day having a similar schedule. If you have full backups once a week, you would change each to have the full backup every other week.

You might be able to achieve redundancy/failover with the existing setup without any additional expense.

You should make sure you have a current baseline of resource requirements by all the servers/applications dealing with CPU needs, memory, disk I/O.  This way you could better pair applications such that there is no impact/decline in performance of the application.

When you say failover, do you mean from server to server or do you mean from location to location (DR type of failover)?
Failover is critical, what happens if you deploy all your VMs on one ESX host and it fails?  Without a way to power up the VMs on another host - whether it be through a fresh rebuild of everything then a restore from a traditional backup (this could take many many hours, have you done a full DR test yet?)   or an HA cluster (happens in 2 minutes automatically) - you'll be dead in the water till the issue that brought down your ESX host is resolved.  You don't want this unless it is a DEV environment.  Always architect production in a way that eliminates as many points of failure as possible.  Putting all your VMs on one basket is a huge risk and exposes you to a huge point of failure.  

and to reply to Arnold's comment:  The benefits of VMware aren't dependent on ROI, ROI is merely a case for the investment.  Management has to be sold on it before you can start working with it.  From an engineering \ admin perspective, its all good, especially when it comes to DR.  VMware is a hard sell to small environments, this is way Vmware restructured the licensing and introduced vSphere essentials.  Its hard to go wrong when you can license 3 hosts, vCenter, and get support for only 3k.  

In fact, what i have done with many clients is perform a P2V conversion of current systems and then rebuild them as ESX hosts, then import the P2Ved server back into the environment.  This brings down the initial investment of new servers.  I think the best course of action is to build an environment on new hardware with hardware virtualization capabilities, then use guided consolidation tool to P2V your physical servers after you have collected data.  However, I have also set up windows perf counters at customer sites to get a solid look at an environment to properly architect an environment from the get go rather than wing it.  There are many approaches, but in the end they all lead to many benefits.  

Try this - download ESX and vCenter for free, use the 60 trial license, P2V some of your servers into the VMware infrastructure you built and test out the apps before you go live with anything.  This way you are protecting yourself as much as possible from unforeseen performance issues that could arise that are a result of applications that simply aren't good candidates for virtualization.  
In regards to failover, define your SLAs for each application, how long can they afford to be down?  decide whether your "failover" is really for business continuity or DR, there is a difference.  The question always comes down to "how long can I afford to be down?"  once you define that you have a better idea of what the best course of action is.  Keep in mind that relying on other technologies \  procedures for business continuity you haven't really addressed the cost of DR.  Does your backup solution provide you with a method for restore a physical server into an ESX VM?  are your backup images compatible with VMware converter so you can mount them and convert them to VMs?  These are good things to have for DR.  If you don't have this capability how are you going to bring back your physical servers should you experience a DR situation?  You can restore physical servers directly into VMs but the process is messy and hit and miss.  I have developed a procedure for doing so.  It really isn't the right way to go and I haven't gotten it to work with w2008 yet once.  In the end you can engineer fault tolerance without VMware all day long, but what is the impact on your DR plan?  Does it complicate it, does it cut costs?  Does it increase costs?  VMware is killer for DR, especially since VMware licenses are floating.  you don't need additional licenses for your DR site, you simply need to move your production licenses to your DR site when you need them.   The big cost of moving forward with VMware is the SAN and its disks and getting licensed for vmotion, which isn't needed in smaller environments but is quite nice to have if you can afford it.      
Hi AngeIIII:  After reviewing all the comments I found za_mkh to be most useful in describing how the benefits work for you.  There aren't any cons to working with VMware, you get HA clustering, the ability to vmotion VMs live from one physical host to another without downtime to the users (this is a more expensive feature for SMB and not needed if you have lots of windows to bring servers down without your users bitching or forcing you to work all hours all the time, keep in mind that VMs power up and down in like a minute, very quickly, no hardware to validate during post, you can power a VM down, migrate its configuration files to another physical host, and then power it up all in about 5 minutes and it is now running on that other host server), you can also leverage virtualization for DR.  You can replicate your VMs via mirrored storage and purchase low cost solution that allows IP based replication of your VMs to your DR site, and you can also replicate physical servers directly into VMs and keep them in sync, check out vision cores product line, and platespin protect software, the both do this, you can then make your environment super efficient by creating VM templates of your standard builds, clone servers and sysprep them automatically, create alerts with email notifications, and so much more.. anyone who thinks VMware isn't the way to go is on glue.  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.