Home / server / Questions / 39954
Accepted
Lester Cheung
Asked: 2009-07-14 08:28:32 +0800 CST

Is mixing IT infrastructure and development VMs into the same physical machine a bad idea?

  • 772

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:

For

  • 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

Against

  • IT and development probably have different (separate) budget anyway
  • runaway development VMs may have adverse effect to core IT services
virtualization capacity-planning

6 Answers

  1. Best Answer

    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.

    • 5

  2. 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.

    • 3

  3. 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?

    • 3

  4. 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.

    • 1

  5. You should always separate Production and Development/QA environments

    • 0

  6. 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.

    • 0