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?
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 :)
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.
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 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.
As others have mentioned it depends on several things:
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.
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.
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.
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.
