Possible Duplicate:
Thoughts on Development using Virtual Machines

My boss has been singing the praises of leveraging virtualized desktops for all our developers in the company - about 100 people. I think this is a horrible idea and can think of no other companies pursuing a similar course of action.

He believes that he can run Word and Outlook much faster over his server hosted virtual machine and has somehow come to believe that this will work for software development just as well. I have grave doubts of this.

Can anyone else provide me with some objective technical and/or business data on this scenario which can be used to dissuade him?

I can see desktop virtualization as a viable option for task based workers who sit in front of MS Office or a LOB app all day, but for software development, I see this as a huge potential blunder. I for one, have no interest in returning to dumb terminals and blind faith in operations to keep the servers and network tuned to our needs.

If such a system is instituted, I may very well leave the company... as I see the policy betraying a clear lack of understanding and a diminished perception of value in what the devs are doing...


Why not give it a try? Offer to set up a side by side comparison so that you can make a fair comparison and so all the developers can take the new system for a spin. You might even switch for a month or two and really give it a shot. Possible outcomes:

  • You have a bunch of problems. Maybe the sys admins don't give you access to the tools you need, or the system is just too slow, or the keyboard makes your hands hurt, or whatever. As the first developer to try the new system, your manager is going to want to know what you think and will probably be eager to help you solve the problems you find.

  • The new system works better than you expected and is at least passable. The biggest downside is that you lose some control over your machine. That was probably coming anyway, though, and by volunteering to go first (and not whining about it) you at least garner some points with your manager.

  • Surprise! The new system really does work well. Maybe it's as fast as your current machine, or maybe it's faster. You might discover some advantages that you didn't have with your desktop machine. For example, I worked on one such system where you could pull your token out of one terminal and stick it in another, and you'd be right where you left off. I still didn't love the system, but it was really nifty to be able to sit down at any desk and access your own environment. Worked great for showing someone else something that you were working on. The downside here is that you have to admit that your manager was right, but you still get the points for going first.

If you give the new system an honest try and find real problems, your manager should be smart enough and honest enough to admit that his plan might not work so well, at least for the developers. He shouldn't be so invested in his plan that he can't see the real problems. But by the same token, you shouldn't be so emotionally attached to the way you work now that you're afraid to try something new.

  • 4
    side by side comparison is what doctor ordered for cases like that. Before throwing about 100 people in completely new environment, the most reasonable thing to do is to set up controlled testing with say 10 guys working on RDPs and another 10 guys performing similar activities on their own machines. If their boss is so dumb that he can't figure this, I think leaving for another job would be the best option – gnat Sep 15 '11 at 6:41

We use virtual desktops heavily and with powerful servers sitting on your LAN and fast storage the performance can be quite adequate for software development. It's not quite up to par with the latest and fastest but it's close. Some of the benefits are being able to quickly replicate and deploy VMs, automatic backups and being able to access your desktop from anywhere (e.g. meeting room, home etc.).

Need a particular OS flavor for testing? Not a problem. You can take snapshots before installing stuff etc.

The feel (this is VMware View) is pretty much indistinguisable from a physical PC. Multiple monitors, USB...

So it really depends. You have to weigh the benefits vs. the small performance decrease. It's not just the cost of a PC but the cost of maintaining that hardware. The initial investment in building a good VDI infrastructure for software development can easily be much higher than the cost of PCs (storage is crazy and servers aren't cheap either).

I've commented on a similar question before, see:


Disclosure :-) We develop software for virtual desktops - hence we eat our own dogfood.

EDIT: expanding on the performance question:

  • The overhead of running inside a VM using modern CPUs is quite small.
  • There are very fast I/O solutions geared towards VDI enviornments (mostly use SSD caching).
  • So in a well architected, unloaded, VDI enviornment "raw" performance is quite good. Again, not as good as a cutting edge stand-alone PC but pretty good.
  • The "residual" cost is the cost of remoting the desktop (e.g. screen, keyboard, mouse) over the network. This is mostly a function of how many pixels are changing on the screen and for software development work is not a heavy load. As a rough guideline I'd estimate that less than 5% of a modern CPU core is required to support this. If you do intensive 3D graphics (e.g.) then virtualization is probably not for you (yet?).
  • 2
    Most modern IDE's are designed to work on local machines, so you'd have to make a pretty strong case to convince me that virtual desktops are workable. Every second you can squeeze out of a compile cycle represents improved overall developer productivity; it's almost always cheaper to throw more money at hardware than it is to pay a developer to sit idle while he waits for a compile cycle to complete, or for his typing to intellisense. Those idle times are a penalty you must pay over and over for choosing inadequate developer hardware. – Robert Harvey Sep 15 '11 at 6:26
  • However, I will agree with you that virtual machines are an excellent tool for testing software under different platform scenarios. – Robert Harvey Sep 15 '11 at 6:29
  • @Robert Harvey: The IDE is running on a "local" machine, the VM. The performance cost of virtualization on a modern CPU with the new hardware assist features is not huge. A few %. There are good solutions out there for I/O performance (e.g. Fusion-IO). So it's really down to the consolidation ratio and how much $ you spend on your hardware, virtualization by itself isn't an issue. – Guy Sirton Sep 15 '11 at 6:33
  • Oh, sorry; when you said "powerful servers sitting on your LAN," I just assumed that you were talking about consolidating your development sessions on some "big iron" servers, and using the desktop machines as "dumb terminals." If you're running a VM locally, the servers aren't really a relevant detail. – Robert Harvey Sep 15 '11 at 6:34
  • @Robert Harvey: The point is it doesn't matter. The compile time isn't impacted by the location of the VM. It's impacted by the power of the underlying hardware and how loaded it is. The VDI remoting aspect here, that is that screen updates, are instantaneoues and neglible. – Guy Sirton Sep 15 '11 at 6:39

I do not see how we can objectively answer this question. Why does it seem so bad? What is your issues with virtual environment?

Although I agree about the issues related to virtualized environment mostly delay in the input and availability. We did use such scenario for a while but get this... programmers and servers were on opposite sides of the globe.

Delay was horrible, yet, we still managed to be productive. Now that does not mean I would return to such an environment - it really was horrible. On the other hand there are many specialized set-ups that we have to use for some aspects of the system's development. For use it is just much more convenient to use a virtual environment and fire it up when we need it than getting all the environments up and running on all the stations.

There are advantages to running in a virtual environment and the disadvantages can be worked around. For example the performance tests it would seem obvious to me that a dedicated hardware would be necessary for this to obtain any sort of reliable results over time.

There are also disadvantages most of which have impacts more on the business side of the job than the strict engineering side. For example availability. Perhaps the company really though it through and estimated that they can cut costs by centralizing the setups even if this means that x% of the time part of or the whole team will be idle due to system outages. That said, true impact studies as these are rarely done properly. Now getting forced time off (paid I might add) might not always feel right but it is their money they are waiting here. Your time has already been bought and paid for, how it is used is really up to them. But like you said, if the way they choose to spend your time feels wrong then you always have the choice to move on.

My point here is that if you want to convince someone of a decision being wrong you have to be ready to see the other side of the coin. Maybe they did not see the problems you are fearing will happen, but maybe you did not see the problems that led to this decision. But how you asked your question here I can just see that this is not going anywhere.


I work on a daily basis (as a developer) using RDP to a virtualized desktop and I would say it's not that practical. Especially when you're doing performance tests you can never do a clean test thus your results are less easy to compare. Adding to that you'll always have some delay between your keystrokes and the remote computer handling your input


As long as you are connected with a reasonably fast LAN and they have not made a complete mess of the sizing and configuration of the servers you should not notice any difference.

There are numerous advantages to these environment:-

  • Some tasks are faster -- large build tasks can take advantage of the extra processing power and memory of the server hardware.
  • If you need to test against multiple versions of the OS or system software you just deploy more Virtual desktops.
  • Its cost effective to deploy many cheaper workstations and a few powerful servers than vice versa.
  • Utilization. Unless all your developers never get sick, never take vacation, never go to meetings and never stop for coffee, then you will get better utilization from the shared server environment -- 90% average cpu, memory etc over a working day as opposed to maybe an average of 10% workstation usage for a working day.

Maybe you prefer a dedicated workstation but its really not worth fighting your boss over.