Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As a system designer, would you put VMs responsible for core infrastructure (dns/dhcp/directory/web/wiki/repos/file share etc) and VMs used for development and testing on the same physical machine?

My take:


  • better hardware utilization - most IT VM has relatively low load
  • ability to spend more on better hardware /w $ coming from different projects
  • less overall spending


  • IT and development probably have different (separate) budget anyway
  • runaway development VMs may have adverse effect to core IT services
share|improve this question
up vote 5 down vote accepted

Generally I would say not to do this. We view development as an area that can and will break due to the nature of the work (infinite loops, badly optimized SQL statements, and all that fun stuff)

I actually treat development environments like test environments for the Operations/networking departments. Although that may not work for you if you need 5 9's up time on your dev environment.

If you must put them on the same hosts, then i would really clamp down tight on their allocated resources so that they can't take down any other services if they have any of the issues mentioned above.

Also another added benefit of having them on a separate host is that you can design a few templates with all required software, then give the devs permission to deploy them and install software on them. This way they don't have to bother anyone if they need to spin up a new server or install software.

One more thing to watch out for would be disk contention caused by a runaway process writing to or reading from disk.

share|improve this answer
Yup - disk performance is always the weakest link... – Lester Cheung Oct 2 '09 at 16:05

To talk to your "Against" points:

  1. True, they are likely separate budgets in larger companies, but some smaller companies might have more limited resources -- especially with major cutbacks in spending.

  2. With options like VMware DRS or Resource Pools, you can easily minimize the risk of a runaway VM.

share|improve this answer

In a small shop, I would.

I would probably try to set things so that development VMs were on a separate vm-net with a separate physical adapter and VLAN, and lock development VMs to specific CPUs to reduce the chance that you'd affect a core-service VM too badly.

Besides, if things get too bad, you can always move the VMs to another server, right?

share|improve this answer
Yes I work in a small shop so it's likely that I will be forced to do so soon. Good point on the fact that you can move VMs when it gets bad. :) – Lester Cheung Oct 2 '09 at 16:07

I can think of one scenario where you'd likely want to have a separate environment for testing in particular.

Say you want to test the new version of the hypervisor or virtual tools you're using to run and manage your virtual environment. You wouldn't want to do this in your production environment.

share|improve this answer

You should always separate Production and Development/QA environments

share|improve this answer
He is separating them, virtually. Do you mean to suggest the physical network and hardware should be isolated as well? – icelava Sep 2 '09 at 2:56

We've done this before without issue.

If you are using Hyper-V, and want the devs to be able to manage their own set of VM's, you will want to check out Authorization Manager. That will let you give them access to only certain VM's and certain operations for those VM's.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.