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?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

What bothers you? It is still for all purposes a computer.
–
user1249Oct 17 '11 at 11:19

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.
–
Scott WhitlockOct 17 '11 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 RayOct 17 '11 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 :)
–
Edward BowlesOct 17 '11 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.
–
Steve EversOct 17 '11 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.
–
Edward BowlesOct 17 '11 at 15:24

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.

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.
–
AllyFeb 10 '14 at 12:31

Environment

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.

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.

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

Before we started using the VM's we were having constant 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 small company and we don't have always the manpower to help new team members to set up the machine. This led to numerous problems: sometimes the bug was reproducible only on their machine or vice versa, or 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 VM's - everything changed. Now only one guy is responsible for setting up the environment in 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 can't take more than 2h). It also allows us to work on multiple working environments.

The drawbacks for using VM's: SPEED. Yes, the performance hit on the VM is visible. On slow workstations it can make development nearly impossible. But if you have good workstation (quad core, 8+GB RAM, SSD) you can work normally (I'm working currently on a laptop with 8GB RAM and Core2Duo processor).

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.
–
Michael KohneOct 17 '11 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?
–
Christian POct 17 '11 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.
–
JeffOOct 17 '11 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.
–
Christian POct 17 '11 at 14:12

Pretty much mirrors my experience. We were developing against WebSphere, so we had the app server, ide, MQ and message broker, plus some in-house tools. Set-up was a hassle. VMs should have been better, but they cheaped out on the hardware, so we were running these 8G VMs on the weakest dual-core CPU Intel made, with only 2G of memory. Did. Not. Work. At home I run VS2010 under Win7 in VirtualBox on my quad-core Linux system with 8G of memory and it's faster than running natively on my dual-core work box with 4G of memory.
–
TMNOct 17 '11 at 15:20

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.

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.