I'll be working as a development lead for a startup and I've suggested that we use VMs for development. I'm not talking about each developer having a desktop with VMs for testing/development, I mean having a server rack where all VMs are managed and have the developers work from a microPC (ChromeOS anyone?) locally, or even remotely from their home computer.

To me, the benefits are the fact that it's extremely scalable, cheaper in the long run, easier to manage and that we utilize the hardware its maximum potential. As for cons, I can't think of any particular showstoppers other than we'll need someone to setup/maintain said setup.

I was hoping that some of you might of had a similar setup at your place of employment and be able to weight in with your opinions. Thanks.

  • 7
    This is not your father's IBM VM/ESA! All the way back to the IBM mainframe.
    – Vitor Py
    Commented Aug 25, 2011 at 2:49
  • 23
    About the only showstopper for me would be multiple screen support. I couldn't develop on less than 2 screens. Commented Aug 25, 2011 at 2:53
  • 27
    There are many exotic reasons: Sometimes you need a USB key to be plugged in to a physical computer for licensing purposes. Sometimes you are dealing with actual CDs. Sometimes you need to hard-reboot the sucker. Sometimes you need to measure performance as it would be on an actual computer. Sometimes you are developing drivers. Sometimes you need all the speed you can get. Sometimes you need to demo the product somewhere without internet access. Sometimes you need to sign-in to a system using fingerprint validation.
    – Job
    Commented Aug 25, 2011 at 3:15
  • 47
    Modern IDE's require dedicated, local hardware. Before even thinking about doing this, you should have a test bed and a study to see if it's even viable. You may learn a thing or two you didn't know about how people interact with machines. If you tell me you don't have the time or money to perform such a study, I will tell you that you don't have sufficient scale to justify your setup. Commented Aug 25, 2011 at 5:29
  • 4
    Just bear in mind that you do need physical machines as well. Our test server are almost all on VM's spread over two SAN hosts. But we do encounter problems where we want/need to verify that virtualisation is not a factor or even the culprit. Also, not all VM's support theming with glass and if you are developing GUI's you will need to check your GUI in a glass themed environment as well. Commented Aug 25, 2011 at 8:04

25 Answers 25


What are you hoping to save, as a fraction of the development budget? It seems to me that you are worrying about an epsilon. The cost of machines for developers is less than 5% of the total cost to keep a developer on staff. Therefore the only important question is "will it save developers time?" It could, if they don't have to spend time installing and upgrading development software. Or it could cost time, if the network goes down, or the server goes down, or, most likely, if the responsiveness across the net is the least bit lacking. Modern development depends on keystroke-by-keystroke interaction with an IDE, or at least a very intelligent editor. Delaying that interaction by even a few tens of milliseconds destroys developer productivity. There is also the cost for developers to learn this new way of working. If that takes even one day per developer, you have already spent more in labor than the cost of a new desktop.

These are not objections to VMs, but potential objections to remote development.

  • I see your point, but the server will be local (same room) as the developers. The latency will be if they work from home, and that latency will be there no matter if it's from a VM or if it's a developer's own box. The development budget includes not only creating development VMs, but testing environments as well. I figured that this method is much more scalable than each having their own box, and easier for support. Thanks for the answer though, it made me think of other things :)
    – J_A_X
    Commented Aug 25, 2011 at 3:25
  • 5
    This approach may indeed save a maintenance time. But probably not at a startup-scale. It must be 20 users or more to start being financially interesting.
    – SK-logic
    Commented Aug 25, 2011 at 5:51
  • 6
    If you locate the server in an equipement room you gain envronmental seperation which is better for the server and the people. Backgound noise in the office is reduced and heat can be managed better.
    – mattnz
    Commented Aug 25, 2011 at 6:58
  • 1
    @J_A_X: That latency would not exist when working from home if the machines are laptops. Network latency over the VPN would certainly be there, but the latency of interacting with the machine itself would not. Commented Aug 25, 2011 at 12:39
  • 1
    @J_A_X: the latency isn't there if the entire development environment is contained in the developer's laptop. And there could still be noticeable latency pushing screen updates across the room, when interaction occurs on every keystroke. Fifty milliseconds delay in character echo would be very painful. Maybe it would all go smoothly, but is it really worth it to find out? Commented Aug 25, 2011 at 13:22

I think you're being penny-wise and pound-foolish.

First of all, machine costs are trivial compared to the cost of a developer. You should work at maximizing productivity, not minimizing machine cost.

Second, latency (not bandwidth) is the key to many programming tasks -- especially text editing. For every dollar/pound/euro you save on machines for your developers, you'll spend at least ten on network upgrades to maintain even a semblance of productivity -- and even then, they'd probably be more productive if you economized by supplying them with Pentium III's you found in a dumpster somewhere.

I also think there's a substantial benefit in having your developers use an environment at least reasonably close to that expected of the target end user. Regardless of official performance targets in a spec and such, most programmers base quite a bit on how the code "feels" when they test it. When they're using a completely different environment from the end user's, they're likely to waste time on trivialities while completely overlooking major problems.

As attractive as a homogeneous environment sounds from a viewpoint of support and such, you should generally encourage as much variety in the developers' machines as possible. Developers rarely need much support anyway, and knowing immediately when you have code that's going to fail with a different graphics chip, CPU, network adapter, etc., more than repays the minimal investment.

Bottom line: if you're writing code that's intended (at least primarily) to be used in a virtualized server environment, you just about need to provide that for your developers. If you're doing it anyway for testing, it can (but doesn't necessarily) make sense for development as well. Likewise, if you need (or at least have) a severely over-speced server and network anyway, it might make sense to take advantage of that by using what you already have available.

Under most typical circumstances, however, it seems to me that this is likely to introduce more problems than it solves.

  • 4
    I know it wasn't meant to be taken seriously, but I'd absolutely take a decent virtual environment over some "Pentium III's you found in a dumpster somewhere"
    – Davy8
    Commented Aug 26, 2011 at 18:52
  • No, no, no. Do not encourage as much variety among development machines. If you need to develop for hardware, then do it properly, using a set of testing boxes that represent the hardware you need your software to run on. You never, ever, ever encourage random deviations in hardware on your individual development machines, it's a software development worst practice.
    – snakehiss
    Commented Jan 5, 2014 at 22:05

That was one of my ideas in the past: having a high performance server which has all the required software, and a bunch of low performance desktop PCs which would be used only to connect to the server through Remote Desktop.

The benefits would be:

  • The solid backup. Some developers may not want to backup their desktop computers regularly, so a central solution would be more reliable,
  • The possibility, for every developer, to work from anywhere. By this I also mean working from any PC in the company. Let's say in the morning, the developer wants silent work conditions. He goes to his own room and works there. Then he wants to do some pair programming or to work in a more social environment. He just shuts down his desktop PC, goes to another room where there are ten computers, and connects from there. No "I must reload all my apps again".

Well, there are several serious problems with that, making me think that I will never use the thing like this the next years.

  • Specificity of remote solutions. What about working distantly using several computer screens at once? I mean, is it easy? Is it obvious? Are shortcuts I use daily enabled when working distantly? I'm not so sure. What if I press Ctrl+Shift+Esc to see the list of programs currently running? Oh yes, it doesn't work, so now I must remember doing it in a different way.

  • Performance hit. I'm not sure there will be no performance decrease at all. And remember, a programmer who uses a slow computer is an unhappy programmer. And the company who makes their programmers unhappy with crappy conditions will never produce high quality software.

  • Higher impact of a disaster. Will you host the solution on a redundant server? Do you have redundant network in your company? Let's say the router goes down, and is not redundant. It means that all the developers are now unable to work. At all. Because they don't have software installed locally. Because they don't even have source code: it's on the server. So everyone stops, and you're paying all those people per hour just to wait the router to be replaced.

  • Hardware costs. If it's one and one only server, how much will it cost? If you have, let's say, twenty developers, would 64 GB of RAM on the server be enough? Not so sure. Would quad-core solution with two CPU be enough? Again, I have some doubts. Otherwise, what do you think about? Some sort of cloud? Or do you have a scalable solution which works on several servers? Are you ready to pay the cost of Windows Server (if you use Windows) per machine?

  • Electricity cost. If you work completely remotely, it means that you spend nearly the same amount of power server-side as if you were working locally, plus the amount of power wasted by the local machine and the network.

  • Licenses. I'm not sure if I must put it as a benefit or a problem, but I feel like the cost of software licensing in this case will be much higher.

And again, think about all the costs of management, support, deployment, maintenance. With a custom solution like this, it may easily become huge, not counting that every time something will fail, you'll see every developer NOPing around, waiting to be able to continue his work.

  • If the server down, you will lose everything. Unless you replicate this server also...
    – Rudy
    Commented Aug 25, 2011 at 6:58
  • 4
    @Rudy: In most shops, if the server goes down, you can't really work locally either (no DB acces for testing, no checkins, no checkouts, no bug tracking access, no email,...)
    – sleske
    Commented Aug 25, 2011 at 8:35
  • 4
    @sleske agreed with DB, email and stuff, but with DVCS you can at least checkin/branch/...
    – mbx
    Commented Aug 25, 2011 at 9:57
  • Most shops, especially one contemplating using VMs on a rack to host development environments, would have separate servers for DB, email, etc. Besides, even if some of these services go down, you still have access to your local desktop and whatever you happened to be working on at the time.
    – Pete
    Commented Aug 25, 2011 at 11:31
  • @sleske - Is there a DB engine today that can't be run on a developer's workstation? Commented Aug 25, 2011 at 14:20

We use on-demand amazon ec2 instances as developer machines. This has nothing to do with cost. We have a "pool of developers" working on several projects, and we need the ability to move across projects quickly.

In general, the VM saves initial setup time. But longer term, it wastes time due to loss of productivity. Cost is a non-axis, because developer cost is much more than machine cost.

Productivity costs include - time taken to start a VM image (several minutes), poor responsiveness, and resource/memory constraints. These are not much initially, but over time they get annoying.

On one of our projects we refactored the code to simplify initial setup to "download code and run maven". With this change, it was simple for a new developer to start working on the project -- and now nobody uses the amazon VM image. We are looking to emulate this on other projects as well, but its going to take time. Till then, we have our ec2 images.


Be VERY careful here. I was recently deployed to a customer where everyone in the IT department had their VM essentially for the same reason - to enable them to have lower end PCs on the desk and then to remote into the VM and do their normal work.

The experience there was not pretty. At least once per week we were running extremely slow for various reasons. Generally, we could tell when someone on the team was running a set of processor intensive SSIS packages. They did eventually move a few of us off to different servers, which helped some, but performance was never right.

I think if you are going to do it - do your due diligence into server power, your processing needs, how many machines you are going to serve up, etc. It could save you some money, but if not implemented correctly, can cause LOTS of headaches.

Please note: this is NOT a flame of VM architecture - just a warning for folks who are looking into it - make sure you have your ducks in a row before implementation.

  • 1
    +1 Do your homework! The guy who did it at my last company had experience and it went off without a hitch. It was the best system I've ever used for development, but took the better part of a man-year to design and implement. Commented Jul 1, 2011 at 1:44

Development on virtual machines can work quite nicely, but only if done right:

  • Just because using VMs allows you to have a single computer for your entire team rather than one per developer doesn't mean that it is a good idea
  • Rebooting should not require opening a support ticket with a 24 hour response time
  • Development VMs should not be in a datacenter 5000 miles away from the developers.
  • While VMs may be managed by developers and therefore unsupported, that does not mean that they should be unable to access network services such as source control.
  • The remote desktop connection should be standard, not some custom "high security" applet that converts any quotes typed into umlauts.
  • Getting a new VM or rebuilding an existing one should take minutes, not weeks

I have seen all of these issues, and don't particularly enjoy working with them. However I also have a VM setup at home which I use by choice. That runs faster than a local install would and allows things like separate environments for different projects and fast rebuilds when an environment becomes unstable.


I work with VMs, but I do not recommend it for your main project.

The reason I use VMs for development is because I have to support legacy projects (e.g. VB6, .NET 1.1, etc...) and I don't want to dirty my main machine by having to install VS2003/2005/vb6/etc... It works out OK, but there are intermittent issues here and there.

In addition, the interaction is slower, VMs take a while to start/shutdown, do not have native UI effects (like Aero in Win7), etc...

Whatever you are going to save in terms of money you'll waste and more by the hassle you are about to impose on your team. Plus, as someone here mentioned, no multi-screen support. I need at least 3 screens to be as productive as possible.

  • I use VMWare Workstation for development across three monitors.
    – JC01
    Commented Apr 18, 2012 at 17:53

The #1 rule of development is to keep your developers happy. You will find that near-impossible to do with remote VMs. Multi-monitor support is spotty, network lag and blips are troublesome, and cost savings are generally minimal.

Work on VMs, sure, but allow for local VMs too, and make the physical computer a ridiculously fast beast too.

I telecommute 100%, and between my personal ISP and the VPN--despite high reliability--they have enough blips that would drive me nuts if I couldn't work in offline mode.

I generally just spin up a variety of VirtualBox images and work from them. Copying a few hundred MBs over the wire isn't too time-intensive if you need a new one locally either.


My team successfully implemented a "slow PC/Fast VM server" configuration. For a team of 20 developers, we had a 8 processor, 256GB RAM server connected via fiber to a very fast SAN. It was expensive, but cheaper than giving each developer a workstation with similar performance. For a small team (4 developers) I'm not sure the economies of scale would kick in and actually save you anything.

  • 1
    Did you run into issues in other VMs when one started compiling a large project or do other resource intensive tasks?
    – TheLQ
    Commented Jul 1, 2011 at 0:46
  • @TheLQ No problems, but the guy who designed the system had done it previously so the hardware was selected and tuned just for this task. The last I asked him, he said the processors were always mostly idle, but the disks spun like mad. Commented Jul 1, 2011 at 1:35
  • so one san disk was going on the edge with 8 developers - what would you say to ~20? how many san do we require for that task?
    – Toskan
    Commented Jul 1, 2011 at 9:27
  • 1
    @Toskan No, we had 20 developers and 8 CPUs in the server. As for the number of disks, I believe our SAN had 12 disks, but I cannot be certain. Commented Jul 1, 2011 at 12:16

VMs for development are worth looking at, but financial cost is the wrong reason.

This was covered briefly in Marc Holmes' Expert .NET Delivery using NAnt & CruiseControl.net - in short the argument for developing on a VM is that it discourages any aspect of the work from becoming dependent on the developer's particular configuration. You nuke your VM at the start of every project, and unless you actually need a particular tool, it doesn't keep kicking around. This minimises the likelihood that changes you make will be breaking on anybody's machine but yours. Developers might cry at having their toys taken away - but ultimately, reliance on tools is a weakness and anything you can't do intuitively in a clean environment is a smell.

Note that I don't necessarily believe the arguments presented above. I understand and to a certain extent align with them, but I'm making them for arguments' sake, to generate discussion.

  • 7
    That is why you have a build engine - continuous integration should catch such dependencies. Developers, however, need all the tools they can get.
    – user1249
    Commented Aug 25, 2011 at 18:06
  • 4
    Yeah - don't take my toys away. They make me productive to get stuff done. Building for deployment, and testing in a target environment are different problems to be solved. Commented Aug 26, 2011 at 11:09
  • One option is to develop set-up scripts that will copy in your aliases, configuration files and other setup files. For instance on Linux I have an alias set up to pull all that stuff down from git. Commented May 19, 2014 at 11:55

Potential drawbacks

  • If the VM host goes down... you're all hosed. If you've ever had a team of 20 people yell "GAH! HOST NOT RESPONDING!?" in unison... it's not fun.
  • If you're permitting snapshots... those eat up resources quickly. 20 people * 10-20 snapshots each makes for lots of HDD space (or at least enough to start causing problems).
  • If you do encounter problems with resource usage on the host, again, everyone experiences the pain.

IME, it's a good solution and it does work, but you need some decent hardware on the host and when bad things happen, they happen to everyone.


This fails one of the most important criteria of the Joel test.

I make sure all my developers have at least an i3 or better laptop or desktop with as much RAM as it can possibly hold.

8GB is what I strive for.

It makes them more productive, and they can actually run Virtual Box on their local machines for development and testing, instead of on expensive to maintain servers. They can snapshot their Virtual Box install crazy stuff and test different browsers and installers and everything and in seconds be back to a known good configuration without any need to contact "IT" services.

Developers need the fastest machines in the company, with the most RAM and root permissions on their local machines. End of story.


I have worked on VMs before for development, both local VMs (running on the local PC) and remote ones. The local ones were much nicer to work with than the remote ones.

Remote VMs, which we were connecting to by RDP, had a small amount of lag between every keystroke and action. It's possible to develop under such conditions for a short time but day-in day-out it became very frustrating.

I happily developed under a local VM on VMWare because I needed to run Flash Builder on a Linux machine, and was quite happy with it as long as it had enough memory - it was quite usable.

  • I just have to add, that you need a CPU with Nested Page Tables (2.Gen Virtualization Support) to get good performance. Using VM Ware with shared Paths is quite slow when you don't have SSDs (it takes > 20sec to git add or git status on repo with 7k files )
    – mbx
    Commented Aug 25, 2011 at 10:06

We do that for our remote machines and it works fairly well. Most rarely work from home (normally only for an emergency fix here and there) so we just use fairly lowend netbooks, remoted into our speedy desktop machines at the office. They are definitely still slower (probably limited by the network more than anything), but work for short tasks every now and then. This would really not be acceptable for a full time work horse, however, since VM can frequently cause a bit of lag that even with the best hardware, IMHO, is a bit distracting.


At my last job, we did quite exactly that:

We used a Windows Terminal Server, where every developer had an account. The developers still had regular PCs (because they were already there), but the PCs only ran the RDP client.

We did Java development, so the software used where Java compiler + IDE (mostly Eclipse), plus web browser, DB query tools, version control client, and occasionally office sw (OpenOffice.org in our case).

We did not encounter any real problems, and performance was quite decent.

The only real problem was that you really need to take care not to disrupt others in some situations, because you are sharing one system. When IT operations needed to do large file copies or run backups on the server, performance degraded for everyone. When we identified and solved this (by copying with low priority, or overnight), everything performed well.

So the caveat is: Evaluate performance as soon as possible, and plan your hardware and its use accordingly.

  • Can developers install software into these accounts? Sometimes Eclipse isn't the tool for the job. Commented Aug 25, 2011 at 14:26
  • @kevin cline: Yes, sw installation was allowed and possible. However, devs did not have admin rights, so you could only install SW that did not require admin rights to install or run. I could install everything I needed without problems, but I hear there are still apps out there that need admin rights to install or even just to run.
    – sleske
    Commented Aug 31, 2011 at 13:16
  • @sleske In my experience developers should have admin rights on their development machine, virtual or not. In my opinion a developer needs to take ownership of the tools they use and the development machine is just another tool.
    – Manfred
    Commented Nov 2, 2011 at 23:14
  • @John: That really depends on the tools you need. If none of your tools need admin access, you don't need admin access. I don't see why you should always need admin access. Of course, if you need to do stuff like install device drivers or run stuff on port 80, you will need admin access.
    – sleske
    Commented Nov 3, 2011 at 15:18

TL;DR: I've done it at multiple jobs and I now prefer it.

Cost is the wrong reason to focus on. Here are some better ones.


  • Platform consistency in the different environments (dev, test and production).
    • Why: It completely eliminates a defect vector, defects from platform differences in different environments.
  • Allows system changes like upgrades to occur first in development vms, be verified, roll up to test, be verified, and roll into production; all much easier with development (and test) vms.
    • Why: Control. I can snapshot, rollback, identify the deltas, do the change on one server and propagate a success by simply duplicating the vm, etc.
  • Sometimes the systems you develop against are only available on a secured network. Alternatively, the server your software will run on may only have limited access or different network characteristics.
    • Why: The development VM can be on the VLAN that has access to the locked down system or service. Alternatively if the dev server has the same limited access as the test and production server, there is never a question of accidentally coding a requirement on a network characteristic or access that won't be available.


The number one challenge is remote development, especially if you have to go through a gateway or jump server. It makes it difficult, especially if the developers are not well rounded (they have some system engineering knowledge, networking knowledge, etc).

There are many variations of remote development, but they usually boil down to 2 main differences.

  • Run your development tools in the remote environment and use protocols like RDP clients, remote X11 clients, etc.
  • Run your development tools locally and use protocols to transparently sync or execute on the remote server, often using ssh as the transport layer.


There are tools that will help with remote development, and there are IDEs that facilitate it. You will have to investigate to what degree it is capable of remote development, many are not without running on the same server the code is being developed on. However there are other tools.

  • Secure Shell: Most successful remote development setups use ssh to a greater degree, using passwordless logins (using key authentication), transparent multihops (solves the jump server issue) and other configuration options to improve response time. Note: I've always had issues using non-OpenSSH implementations of SSH.
  • GNU Screen/TMUX: Terminal multiplexers. Screen is the granddaddy of them and is still going strong, but I think most people have started switching (or even starting) on TMUX.
  • Vim/Emacs: The old guard, but both work great for remote development in different ways. It's Vim so all it needs is a shell, while Emacs can run locally and use TRAMP for remote development.

On a slightly different tack - have you given your managers/accountants a spreadsheet highlighting the cost of using these slow machines? Point out to them that a VM solution (unless done right, and that ain't easy) might simply put the developers and therefore the company in the same boat.


This will depend on how much adminsitrative power you have over the VMware install, if you are put into a low priority subpool then you will have slow machines depending on the activity of other subpools.


Hardware is cheap, programmers are expensive.

Why would you want your programmers to be frustrated by giving them slow development machines? The cost of upgrading hardware pales compared to the performance benefit they will gain.

Ask for better machines. At the very least ask for 4 gb ram. Adding another 2gb tablet will be earned back in less than a week.

  • problem is the 32 bit windows which is installed on the notebooks
    – Toskan
    Commented Jul 14, 2011 at 8:52

Lack of dual screen support has always been the deal killer. I just can't imagine doing significant development work on a single screen.

Now, they do rock for testing/deployment/fiddling, so I don't think they should fall off the stack either.

  • RDP supports multi-monitor in the newest version. Commented Aug 26, 2011 at 17:56
  • splitview.com/… Commented Aug 26, 2011 at 17:57
  • I thought we were talking about VMs not RDP here . . . Commented Aug 26, 2011 at 18:34
  • Sorry, I was referring to remote VMs. You can do multi-monitors with VMWare Workstation 7+ Commented Aug 26, 2011 at 19:54
  • I think it depends on the size of the monitor.
    – Manfred
    Commented Nov 2, 2011 at 23:15

If you have a mainframe with 50 SSD disks in RAID10, and only use 3-4 machines on that mainframe, then it might work.

Otherwise they are laggy, really laggy (although in some rare cases snapshoting can offset that).


I have a decent desktop machine at the office which I can connect to from my laptop over VPN using screen sharing.

It works for out of hours support incidents and the occasional forced remote working. It is certainly better than maintaining a fully configured environment on a second machine, or for developing stuff that needs low latency to the datacenter across a WAN.

However, it is frustrating to work that way for long periods. I have on occasion driven in to work for the second half of the day once whatever it was that kept me at home has been got out of the way.

Latency and screen real estate are the two killers for me.


I don't think you want to go with a remote VM solution. The network connection will be the bottleneck and even on a fast connection, it can be enough to cause frustration. We are moving away from this technique to using local development environments.

We develop on iMacs, which is really nice, but our web applications are running on a Linux environment in Production. The problem with this is that eventually, we may run into an issue that only happens on Linux and could be difficult to troubleshoot. That's where the power of virtual machines come in. However, I don't even like the idea of using a VM 100% of the time.

I recently learned about Vagrant (http://vagrantup.com/docs/getting-started/why.html) and Chef for making working with VirtualBox super easy. Vagrant gives you the ability to easily start up a VM when you need it, and tear down a VM when you don't. So I could do all my development using my Mac. Then when I'm ready to test my code, I can start up a VM to test it out, and only keep it around as long as i need it. Vagrant also gives you the ability to easily share VMs with your co-workers so that you all can be sure you are working in the same environment.

I would recommend checking out Vagrant so that you are at least aware of the options available when it comes to developing on and working with VMs.


I have been working on a legacy-project concerning 5 machines, each one has a role in a computation pipeline (machine 1 sends request to machine 2, ehich in turn will send request to machine 3 etc). The setting deployment on virtual machine saved us HUGE time however: 1. The system was undebuggable as devs were lazy/did not have time to encorporate testing in the design. 2. Too many setups were deployed on and I needed to consume time on arranging them in groups.

Now I use it because I work on too many projects at once. The main problem I have now are: 1. VMs are consuming way too much time to maintain. 2. VMs are consuming enormous amounts of memory to run

This kinda renders VMs hard to use when you try to use them to have order. Keep one main machine with your email and text, develop on dediacated VMs. Keeps your life neat and clean at a cost.


As stated by others, it really depends on what problem you're trying to solve with the VM Desktops and then weighing the benefits of resolving that problem against the disadvantages the VM environment will incur.

We're moving towards a hybrid environment where all of our onshore developers will have traditional physical machines but out offshore developers (working with a small outsourcing company right now) will use virtual desktops. The problems we're trying to solve with the remote desktops are security and performance related. The virtual environment will obviously provide us greater control from a security perspective and for performance we will be transferring only "changed pixels" rather than full source code and having to implement proxy servers and such.

Still not sure if this is the right way to go, but it's where we're headed.

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