Advice on running my development tools in a virtual machine

Question

I am starting to get quite sick and tired of setting up all my dev tools every time that I need to move to a new machine, or get a laptop, or screw up my registry with constant installs and uninstalls.

So new plan. I have heard of people virtualizing their development environment and this sounds like a great idea. Only problem is that I have scant little experience with running virtual machines so I do what I always do when I just don't know, I ask stackoverflow.

Do you run your development environment in a virtual machine? What should I look out for? What are the non-obvious advantages?

I've got the free version of VMWare server installed on a Dell Optiplex 760 with XP that is on my company's Active Directory domain.

In it I created a 25 gig VM called Dev Tools with XP installed, this is not on any domain. This is where Visual Studio, TortoiseSVN, Git, Ruby, Toad, etc are going to go. I will also create a virtual disk for storing code files.

Some more questions:

• Should I do my daily web-browsing on the host machine or should I spin up yet another VM for it? What is the rule of thumb to use when deciding whether to install an non-dev application (like GIMP) to the host or new VM?
• What about my development database? Should that get its own VM?
• What is the best arrangement of physical hardrives? Should I avoid having the host and client VM on the same one? I am planning on getting an SSD - how do I optimize the speed that this will offer?
• Developing .NET without admin rights is a pain in the ass but should I bother running as administrator on my host machine?
• Any good solutions for backing up my 25 gig dev tools machine? How frequently do you take backups? I don't want to restore it a year from now and have to spend days updating every single application on there.

Answer 1

I've found it highly preferable to use a VM OS for development instead of a base OS. The ability to easily back up your entire dev environment when it's working great, and restore it in 5 minutes if something horrible happens, is such a relief.

Our team used a reference VM with all the developer tools installed. New developers would get a copy of the reference VM and were free to use it as they wished. We used a single VM that contained the IDE, client, app server, and database server, as that just made everything much simpler. I don't think that putting these in different VMs would have offered any advantages.

For web-browsing, I found that it doesn't really matter whether I did it on the VM or the base OS -- most of the time I would just use the VM. As for custom apps, they were generally installed on the base OS. On several occasions, team members (myself included) ran into a problem or made some mistake that caused some part of their dev environment to screw up. Instead of spending hours to fix the problem, we would just grab the reference VM again, update the code, and start fresh. So it's best not to be too tied to the VM -- installing custom apps on the base OS and saving important stuff to either the base or a network drive allows this quick replacement.

Answer 2

A virtual machine is just that...a machine. Browse wherever you want. I do my browsing on my main machine, but I also use Foxmarks to keep things synced across machines so where I browse doesn't matter so much.

If you have the disk, CPU, and RAM on your host box, I'd suggest setting up the DB on a separate box. That allows you to easily move it somewhere else (even a physical host) later if you need to. It also forces you to work in a (likely) more realistic situation of having the db machine be remote from the app machine.

If you can swing it, having the VM hard disk images (or better yet raw HD access) on different physical disks and controllers will typically give you better performance. I wouldn't worry about it too much for a general dev box, though.

In general running as an admin in your dev environment is a good way to accidentally have access dependency problems. Principle of Least Privilege applies.