Workstation in a virtual environment?

[brandonb]

Hi,

I'm all curious what the rest of the world users for a development workstation in their careers. My work has been pushing big on virtualization, but every test we've done, the lag has been pretty bad between our buildings. Not to mention they have about 12ghz of power (a 4 core 3 ghz machine) for 5 developers plus all our source control and our development database servers, etc.

I keep trying to tell them that our developers will not really be happy unless they are working locally on their machines. Sure, for servers, no big deal virtualization ok... But when we are constantly fighting with the virtual machine, and dealing with latency, it's becoming a chore.

They keep trying to tell me that's how the industry is going and most developers these days are working through a virtual environment. In my experience, I've never worked in a virtual environment at any company I've worked for.

So, do you work with your main development coding box hosted in a virtual environment?

 

[BoberFett]

I've always been in small companies, so I can't speak to large corporations and their policies, but I would rather my developers work locally and they seem to prefer it that way. Developers make a mess. It's just the way it is. No need to try to force them into a rigid IT structure in my opinion.

 

[dinkumthinkum]

You're conflating several things here. You don't need virtualization to do remote server time-sharing, and you don't need time-sharing to do virtualization. I've been working on programming projects remotely via SSH for ages. Sharing a hefty server with other users is fairly standard, either through a terminal or X11 protocol. Or alternatively, I am stuck on a workstation that is not mine, and so I login from remote to my own workstation.

I also do work inside of virtual machines on a local computer. One of the main reasons is kernel work, but I could also be stuck on a Windows machine and not feel like installing MinGW. With hardware VT support, running a Linux virtual machine feels effectively just as fast, sometimes even faster, than the host Windows OS.

Working remotely may make sense for your business, I don't know. So my first question is: why virtual machines? And the second question is: which VM software? The latency of the VM running across a network link and displaying locally on your monitor can vary depending on how it is done.

 

[iCyborg]

I didn't notice much problems with latency and network in general, perhaps your LAN switches/routers and/or VM setup need modernization. 4-5 people per physical machine is a bit high. Although it could be OK since most of the coding time is spent in IDE reading/writing code or some other documentation, unless everyone is recompiling all day long. Running tests is also ok, if they are not load tests; for that you should have a dedicated test machine. And if you're developing for multiple OS-es, it's much more convenient to have multiple VMs than multiboot, you can run them at the same time too. And your local machine will not be tied up if you do have to run a long compilation or something else demanding.

My take is that unless you're developing drivers, or something real-time that doesn't cooperate with VMs very well, I'd actually prefer to have dev/test machines virtualized. Actually, it don't even need to be virtualized, I'd prefer not to to dev on a local machine that you use for everything else (email, posting on AT...).

I've always been in small companies, so I can't speak to large corporations and their policies, but I would rather my developers work locally and they seem to prefer it that way. Developers make a mess. It's just the way it is. No need to try to force them into a rigid IT structure in my opinion.

It seems less messy to me when it's VMs. If you foobar the machine, you can just restart from a VM image, instead of having your local machine reinstalled. You can also make snapshots, you can easily share dev environments between developers, you can restrict net access to lan only, you can more effectively use computing resources since most of the developing time is hardly resource intensive etc. There are quite a few benefits IMO.

 

[mosco]

My company did a pilot program with Vmware lab manager. The idea is that you have some dev templates that you check into your workspace, do some work on, and you can get them duplicated into other's people spaces if they needed to reproduce something, etc.

I think VMs have their place, but I don't think they should ever replacement a developers primary workstation. I think they can be great compliments. For example, if you are trying to run 2-3 instances of jboss/tomcat and want to run one of them on another machine, you have your sandbox to work with it. Other times you might want to take a snapshot of something and be able to reset it. Other times you want to give access to it to someone else so they can test something, etc.

The biggest issue I had was just I/O speed. Our build is very I/O intensive and usually takes about ~12 minutes on my workstation. It was a lot slower on my VMs, especially windows VMs for some reason.

I think in theory its great, and I still use a VM from time to time if I need some extra resources but I don't think they are ready for primetime quite yet.

 

[Markbnj]

I haven't worked that way in the past, but I have been starting to think about it more and more just from a local tool management perspective. Probably half my colleagues keep separate VMs for different toolsets, and work off of those.

 

[BoberFett]

I haven't worked that way in the past, but I have been starting to think about it more and more just from a local tool management perspective. Probably half my colleagues keep separate VMs for different toolsets, and work off of those.

I have no problem with using VMs locally, but being stuck on a server which is in all likelihood managed restrictively by admins sounds like a pain in the ass for developers and will probably reduce productivity.

 

[Markbnj]

I have no problem with using VMs locally, but being stuck on a server which is in all likelihood managed restrictively by admins sounds like a pain in the ass for developers and will probably reduce productivity.

No doubt, and agreed, but why should programming be the one thing IT doesn't suck the life out of?

 

[DaveSimmons]

I have a collection of VMs that I run on my desktop for testing purposes, but I wouldn't want to be running my development tools off of a server.

I have thought about setting up a development VM to run on my desktop, since that would allow instant migration to another desktop in case of a hardware failure. That would probably work well if it was running on the desktop.

 

[veri745]

We don't use VM's, but we do use several build servers via ssh / x11, and networked storage for source code.

The build servers are either 16 cores / 24GiB RAM or 24 cores / 32GiB RAM. A few servers like that shared among a couple dozen developers works pretty well. I do most of my dev work in notepad++ accessing the network storage, and then compile over an SSH terminal.

 

[sourceninja]

We have a heavy VM infrastructure here. I put it in place 6 months ago. We have two classrooms using it as well as several faculty and staff members (Including my boss the CIO). There have been no complaints about speed or issues with the virtual machines.

I personally used one without issue for 2 months during the testing phase (before finally going back to my macbook). I found it worked great for my development work and administration tasks (besides being windows and not what I was used to).

Our solution is a combo of a few different technologies. We use vmware on the back end to host the virtual machines (vpshere 4.1), Unidesk to make creation and management of the machines a breeze, and Pano Logic to deliver the virtual machines to their 'no client' device (it's a thin client). Our backend consists of 1 server to host the Unidesk master cachepoint and management appliances (and other servers we virtualize). and 1 server per 35 desktops. The desktops are hosted on local disks on those servers with the server's cachepoint hosted on our san via fiber. The desktop servers are dual 6 core intel machines with 96 gigs of ram.

This allows us to use cheap local disks for better IO on the desktops, while still backing up the user's layers to our san in case anything happens. The direction we are taking is to remove all desktop PC's on their replacement cycle. Going forward we will only be supplying virtual desktops and notebook computers (except for cases where local hardware is truly required like 3d design classes). I'm rolling out 50-75 more desktops in june.

Our long term plan is to remove the need for the thin clients for students (not for staff/faculty) by integrating vmware view and requiring students to purchase their own notebook computers. This way they can connect to a dedicated VM that has all the tools needed for their course load. This vm can be backed up to protected their work and protect them from themselves if they are not 'computer savvy'.

That said the pano devices are very snappy and can even do 720p video on our network without issue. I think our end state will be somewhere around 300-500 pano devices and maybe about 1800-2000 total virtual desktops.

 

[Crusty]

At my new job we share a single virtual server between the 5 developers, 24 cores and 48GB of RAM.

It usually works out fine, but sometimes if someone is running some analysis in Matlab and someone else has a make running the load can shoot up over 50 and things start to get slow. Writing code is usually fine with that load, but if you need to make and then run the unit tests at that point you could be sitting for 30 minutes.