We are a small web software company (~ 10 people). At present, every dev works on his local machine (some windows, some ubuntu) using a local apache. We have a samba share for shared files and central SVN repositories.

I would like to centralize our infrastructure in the future, making everybody work on a central server. There are 2 options:

  • Virtualization: everybody gets an own virtual box on a central, fat server.
    Pro: quick setup, isolation of the users, new boxes added fast.
    Con: as every user has its own OS, a little hungry for hardware. Updating software (new Eclipse versions etc.) does not affect everybody unless they start to use a new vm, which leads to fragmentation or lost working time again. Potential security issues due to missing security updates and users using the box as root.
  • Remote Desktop: everybody connects to a central ubuntu server, using a remote desktop from there. Options are a real X client, xrdp, VNC and the like.
    Pro: easy to use, central data storage, software updates effective immediately, central control easy. Does not need as much hardware. Users are not root. SVN repositories might be local, meaning speedup.
    Con: users are not isolated (potential security issues inside of the team), an apache restart etc. hits everybody.

Both solutions need a fast network and a fat server. At the moment, I would tend to use xrdp as remote desktop access. What experiences do you have? Any downsides to one approach over the other? Options I've missed? Is there anybody out here that successfully virtualised a software dev team?

  • a chroot jail might solve the non isolation part of it en.wikipedia.org/wiki/Chroot – Journeyman Geek Apr 7 '11 at 10:40
  • 1
    having developers on terminal services is not something I'd highly recommend. It's a great deal slower than personal (powerful) desktops. Remember that happy developers produce happy code. – pauska Oct 11 '11 at 11:50
  • The way we takle this is to let devs keep their preferred environment and use them for testing, But then we use a central repository and bug handling system. this because as you stated an apache restart affects al, but also if someone accidentally makes an infinite loop, or needs a tool that will break most of the other code there will be a lot name calling to say atleast – HTDutchy Oct 11 '11 at 12:44

The cons you described are not really actual, in the modern IT world. Hardware is pretty cheap, and the ROI seen when virtualization is used is high and quick. Software updates and management are easy to manage using chef or puppet. Security issues are localised to a single VM, and not to an entire terminal machine, and if you pick the right solution, security, at the update level, is handled by the vendor. BTW, to speed up repository access, use git - your developers will fall in love with it, once they get over the initial shock

With a terminal machine, resource management might end up being pretty hard, with VMs, you not only get better resource allocation, you also get a better justification to get better hardware.


The approach of giving everyone their own virtual machine is far less efficient in terms of memory than a shared system - but it does it make it much easier to allow people to run different Apache configs concurrently. It's also simpler to manage scalability - you can migrate the VMs onto new hardware as required. While you may not expect to be suddenly taking on more staff, both these approaches mean that you can't easily do perfromance scalability testing on your apps (so being able to migrate a user onto a dedicated machine for a couple of days sounds like a good idea).

There are some great tools for managing 'clusters' - most of which would apply to maintaining multiple desktop machines - since you're already running Ubuntu, Canonical's Landscape is an obvious choice. However if it were me, I'd go with a standard build then move the users home directory outside the VM onto an NFS share. And some cunning plan for /etc/sudoers so the user could get root access on their 'own' machine.

  • Good point about performance testing, although I think we would rather use a staging server for this, as we do now. The cluster management would apply to the thin clients as well as to the virtual machines, eliminating the software version problem... also a good point. So many options! So little time ;-) – Steffen Müller Apr 8 '11 at 12:27
  • Memory sharing efficiency is not a big concern if you enable KSM with KVM virtualization technology – sumar Dec 10 '11 at 20:14

Try NoMachine (NX). It has a free offering as well as commercial solutions. It's lightweight, fast, has a pretty universal set of client applications and uses ssh as the transport. You could also combine NoMachine with virtual systems for differing levels of isolation, if needed. You can run NX against a server running in text mode. As long as the GUI elements are installed, users will get full-screen X sessions (that can also span monitors).

  • I think I'll try xrdp first and come back to NoMachine if I see that we need all the bells and whistles it provides. Do you have any experience with xrdp, comparing it to nomachine? – Steffen Müller Apr 8 '11 at 12:31
  • No, I only have experience with NoMachine in this context. The bonus was the free solution and the strong support for Mac, PC and Linux clients... They were also promising a replacement for Windows RDP, but that's not in place yet. – ewwhite Apr 8 '11 at 12:57

We have 3 developers and we use Remote Desktop (except we don't actually use RD because its a website we're developing so we develop the code using "remote file browsing" on either Eclipse or Notepad++ or Coda and view the site through the internet). I think it works well, and the advantages of simultaneous updates are awesome. We're not so concerned with security within the team, so I can't speak to that concern. Apache restarts take 2.5 seconds, so who cares?

edit And I use windows while the other two use Mac. It work great for everybody.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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