This post by Rob Conery (note the slug) says that development environment should be run inside a virtual machine. I see what he's saying and tend to agree, but still feel a little uneasy. Now that virtualization is so mature that even production systems run inside VMs speed is pretty much a non-issue, but as I say something bothers me here.

What's your take on virtualizing your development machine? Have you already done so? If you did, any pitfalls or gotchas along the road?

  • 1
    What bothers you? It is still for all purposes a computer.
    – user1249
    Oct 17, 2011 at 11:19
  • 2
    possible duplicate of Thoughts on Development using Virtual Machines
    – JeffO
    Oct 17, 2011 at 14:05
  • What's a development machine? Developer's worksation or a shared development enviroment?
    – user606723
    Oct 17, 2011 at 14:58

8 Answers 8


My experience with developing on VMs in a corporate environment is that due to virtualisation of multiple cores being fraught with difficulties, it's difficult to get the kind of performance that many enterprise development machines need.

Getting the code-compile-test inner loop to be as fast as possible requires the best machines possible - compilation and the running of tests obviously run faster on machines with more cores, as those activities can be quite easily be executed in a concurrent manner*.

Until mainstream development OSs can deal with the number of available cores being volatile, and until virtualisation software can intelligently offer some kind of "up to N core" contract, virtualised development machines will not offer the same kind of productivity returns as physical devices.

EDIT: This just recounts my personal feelings on developing using corporate-dictated VMs, which are often proscribed to cut hardware costs, which tend to run on servers. Running a local VM seems mostly superfluous provided you're enforcing good source control discipline, unless your project specifically requires you to develop code for multiple OSs.

*:by which I mean the subtasks inside the compile stages and test stages can be run concurrently, NOT compiling and testing concurrently :)

  • +1 - this was my experience with developing on a VM. The performance hit just isn't worth any potential gains. A development machine just can't be fast enough. Oct 17, 2011 at 11:35
  • I've never done it (besides for multi-platform testing), but in principle, couldn't the VM be spec'ed up to crazy speed? The UI could be slowish but you could throw a lot of server room iron at the compilation step, couldn't you?
    – Dan Ray
    Oct 17, 2011 at 12:22
  • 1
    In principle, sure! Defining a VM with buckets of memory and 20 processors is not the hard part. The hard part is when you have a dozen high-spec VMs on the same server - if you have 12 single-processor VMs on a 8-cpu server, each VM gets some CPU time when one processor becomes available. If you have 3 VMs with 4 cores each, you have to wait for 4 CPUs to become free before each VM gets CPU time. Not to mention then needing to context-switch all those cores... it becomes difficult. I've not heard of it being done satisfactorily on a large scale - which means nothing :)
    – user14609
    Oct 17, 2011 at 12:28
  • 1
    +1 This is my experience as well. It's somewhat offset by the benefts of having checkpoints and zero setup for new dev environments, but performance is not the greatest. Oct 17, 2011 at 14:03
  • 1
    @MarcoDinacci Fair point. I would argue that with proper source control, you shouldn't need to be inside a VM unless you are developing for multiple operating systems.
    – user14609
    Oct 17, 2011 at 15:24

I do all my personal development in VMs. I have several VMs setup for different environments and it works fine.

I have a dell studio 15 laptop (quad I7 2.8ghz, 8gb ram, ati graphics) running win 7 ultimate 64bit with virtualbox installed on. I have all my VMs running off an external 500gb usb drive velcroed to the laptop.

VM 0 - Win 7 64bit clean install as base template

VM 1 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) with Visual Studio 2008 toolset

VM 2 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) with Visual Studio 2010 toolset

VM 3 - Win 7 64bit (2 cpu, 2gb ram, 120gb hd) with Eclipse Java toolset

Unless I'm doing something that requires very high IO, I have felt that performance is good and I wouldn't know I'm inside a VM if someone had just handed me the laptop and said start developing.

  • 1
    I also run something similar, the big problem though is once you have a Visual Studio solution with lots of projects you end up waiting minutes for the project to start up/ Disk I/O bottlenecks just to hard. That said I still use the VM whenever this isn't an issue, it's excellent having a portable environment.
    – Ally
    Feb 10, 2014 at 12:31

I would like to add that certain types of development are much more difficult (if not impossible) through virtualized machines.

I happen to work at a company where we offer software packages that integrate with a number of different USB peripheral devices (Eg. webcams, label printers, magnetic stripe readers, etc...). Even if I were to map USB ports to a virtualized server I have noticed bizarre and inexplicable problems with the third party vendor device drivers.

Like I said, I don't think this situation warrants NOT working on virutalized development machines, however it is one that we haven't figured out yet, thus we maintain physical workstations for different environments in a lab.

  • 1
    It's also a pain if you need to use a Remote Access Security card to connect to TFS or something. Oct 17, 2011 at 14:04

In our company we are now using the VM for development and testing. Although there are some drawbacks for using VM's their benefits significantly outweighs them.

Before we started using VMs we had problems with setting up development machines for new developers. The first task for new developer in the team was usually to set up his own development machine. We are a small company and we don't have always the manpower to help a new team members to set up their machine. This led to different problems: sometimes the bug was reproducible only on their machine or they couldn't reproduce it at all, the application could not build properly etc. Also there was also a problem that some of our senior developers were working on multiple projects on working environments that were not always compatible.

When we switched to VMs, everything changed. Now only one person is responsible for setting up the environment in a VM with everything that is related to the project. When he's finished all team members are provided with the copy of the VM. This reduces the time for setting up the environment for every new team member (copying the VM should not take more than 1h). It also allows us to work on multiple working environments in parallel.

The drawbacks for using VMs: speed. The performance hit on the VM is visible. On slower workstations it can make development nearly impossible. If you have a good workstation (quad core, 8+GB RAM, SSD) you probably won't notice it.

  • 1
    Have you considered doing some work to optimize your toolchain? If your tool setup is so complicated that they can't be installed easily, perhaps you need to re-think the tools a little. Oct 17, 2011 at 12:32
  • It's not just about toolchain it is more about the time to set up the machine and troubleshooting problems on different environments. Why would someone need to spend 2 hours installing / setting up something when someone else already did that? Oct 17, 2011 at 12:39
  • Why can't you create a dev machine and take an image to create additional instances? This assumes you all use the same hardware.
    – JeffO
    Oct 17, 2011 at 14:03
  • @JeffO You have more flexibility with VM because it's not so hardware dependent. It would be ok if we were all working on the same hardware, but we're using laptops / desktops. Oct 17, 2011 at 14:12
  • 1
    Just curious -- does your team have people leaving/coming in so often that you care about setting up new machine? If so I suspect stabilizing the team would give you much more productivity gain. (Setting up the human is actually the bottleneck, as opposed to the machine, I guess)
    – kizzx2
    Oct 17, 2011 at 17:18

As others have mentioned it depends on several things:

  • What does your environment look like?
  • Do you have sufficient access rights to do development?
  • Is your HW up to snuff?


Using a VM can help if you are working on multiple versions of a project; multiple projects; or targeting a different OS from the one you normally run (host OS). I do a lot of SharePoint work and being able to run a different machine for the various versions of a release is helpful since I can just start a different machine and have a good feel for the state of the GAC / database. Also if you need to target a *nix application environment but have a Windows machine then you can still do development in a VM (this is how I'm learning Ruby at home even though I generally do .NET dev work). I generally advocate when doing ASP.NET development testing/developing on the same version of IIS that the app will ultimately run under (this same rational applies to other server target environments). Depending on the version of OS there may be some small but critical differences. Note this doesn't imply you should code to a specific version of IIS / OS but let's be honest it really, really has to work where you're going to deploy it not just on your local machine.

VM's also (depending of the software used) allow you to take snapshots of the current machine state and / or clone them. This can be invaluable when prototyping something and you don't have to be as concerned about what is happening in your GAC / Registry / etc. I've also found them very valuable in setting up for a client demo ahead of time. Because the demo environment was in a VM I could continue working right up to the point of showing the client what we had completed because I was working in a different machine.

Sufficient rights

This generally applies to people that work for a company with a rather uptight set of policies for access rights. If you are unable to have unfettered admin on your machine this would be a good time to work in a VM. Typically the powers are only worried about locking down your host OS, the guest can be wide open (permissions wise). I have run into weird problems with roaming profiles, crippled admin rights, and running VS 2010; using a VM allowed me to avoid these problems.

Is your HW up to snuff?

This boils down to either your VM images are on a server and your remote into them OR you run them locally. If you are running on the server then the biggest concern is probably going to be are there too many VM's running on the same hardware. Locally you basically want plenty of RAM and to minimize how often you overload the R/W buffer for your hard drive. For basic LOB / SharePoint / ASP.NET development I've found that a minimum of 8 GB of RAM and a dual hard drive configuration works just fine in practice (running an i5 but I've worked with a Core 2 as well). The second hard drive makes the biggest difference in performance.

Note: I don't have any stats to back this up but I've noticed that Virtual PC has a tendency to underperform compared to both VMWare and Virtual Box. I can't speak to Hyper-V since I haven't worked with it. I wouldn't be surprised if using Virtual PC (as an initial foray into using VM's) jaded developer's on using virtualization software.


As usual: it depends. For example, I certainly wouldn't recommend it for any real-time or computer game-related development.

My personal experience: I have a late-2009 iMac, and I found that Visual Studio 2010 is basically unusable in Parallels Desktop, to the point that pressing a key in the code editor takes a matter of seconds to register. Windows in SQL Server Management Studio would defocus and switch focus apparently at random. I just ended up going with boot camp.

Of course, a new project of mine will involve an iOS application with a Windows-based configuration tool, so it may be too painful to not use virtualisation, but if desktop virtualisation technology hasn't moved along enough in the last year or so, I'll probably just set up another desktop here.

When it comes to testing a server application, that's a different situation, I'm perfectly happy to virtualise that, but I need responsiveness in my development applications.


I have used VMs for development and by and large it is not tremendously different from developing on my own machine. If you're using Source Control properly there aren't many differences.

The main differences are that if you are offline for any reason you don't have a development machine available to you, so not so great if you travel or work from home a lot. Also I never figured out how to run multiple monitors on Remote Desktop, but I'm sure that is my failing rather than a problem with the principle. I usually used my main monitor for development and kept the second one for my desktop machine with email, browsers and so on running.

I'll add that if you're working in a way where you need to check your code works on different platforms - particularly stuff like developing installers - then being able to run up VMs for different OS versions is amazingly handy.

  • 2
    You don't run your VM's on your own machine?
    – user1249
    Oct 17, 2011 at 11:19
  • 1
    Some times, in corporate environments, people are allocated VMs running in a data centre, rather than having machine images locally.
    – user14609
    Oct 17, 2011 at 11:25
  • When I've done it I've been running them on a VMWare server.
    – glenatron
    Oct 17, 2011 at 11:26

I used them at the previous company. Several third party controls did not co-exist well with other versions by the same company. I also used a couple for testing and debugging other operating systems (XP vs Vista vs 7). One virtual had VB6 and VS2003 for the older products. Yes, on a typical developer's machine it can be slow and cumbersome, but I had a few spare hard drives that I "donated" and put the virtuals on their own hard drives on their own drive controllers. I was the last guy to keep using virtuals, and for some bugs, only I could work on them (due to operating system and component concerns).

Some of the guys got burned installing beta software, and some of the betas from MS could not be removed, so they were forced to use virtuals until they reformatted their hard drives.

For developing in virtuals, my advice is to get something with a min of 8GB of RAM. 16 or more would be better, as you'll find any visual studio equipped virtual needs about 1.5GB of the host's RAM to run at speeds above "glacial". Also, get lots of hard drives when buying a computer. For drives you pick out of your spare hardware pile, look for ones at least 2x the size of the VHD you will be running.

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