Development Environment in a VM against an isolated development/test network

Question

I currently work in an organization that forces all software development to be done inside a VM. This is for a variety of risk/governance/security/compliance reasons.

The standard setup is something like:

• VMWare image given to devs with tools installed
• VM is customized to suit project/stream needs
• VM sits in a network & domain that is isolated from the live/production network
• SCM connectivity is only possible through dev/test network
• Email and office tools need to be on live network so this means having two separate desktops going at once
• Heavyweight dev tools in use on VMs so they are very resource hungry

Some problems that people complain about are:

• Development environment runs slower than normal (host OS is windows XP so memory is limited)
• Switching between DEV machine and Email/Office machine is a pain, simple things like cut and paste are made harder. This is less efficient from a usability perspective.
• Mouse in particular doesn't seem to work properly using VMWare player or RDP.
• Need a separate login to Dev/Test network/domain

Has anyone seen or worked in other (hopefully better) setups to this that have similar constraints (as mentioned at the top)?

In particular are there viable options that would remove the need for running stuff in a VM altogether?

Answer 1

It sounds like a big problem is not having enough horsepower on the host OS. WinXP should be fine, but you need to have adequate hardware. i.e. at least 3 GB RAM, dual core CPU, and hardware that supports virtualization. Clipboard sync should be working with the VM.

I am not currently doing this, but I've thought about it, and we're kind of kicking this idea around with the idea of making it easier to standardize the dev environment, and to avoid wasting a day when you get a new PC. I'm dismayed to hear that it's not the utopia that I had dreamed...

Answer 2

In particular are there viable options that would remove the need for running stuff in a VM altogether?

Given that you said there are unspecified risk/governance/security/compliance reasons for your organization's use of VMs, I doubt any option we could provide could negate those. Ultimately it sounds like they just need their development team as sandboxed as possible.

(And even so, the question/answers would probably be better off at serverfault since it's more networking/security oriented.)

Answer 3

I've been using VMs as a development environment for a long time. There's nothing inherently wrong with it, and it presents lots of benefits.

• Ensuring a consistent environment
• Separating file systems for different backup scenarios
• Added security
• Potentially gives developers access to more raw computing power.

There is a lot of innovation in the VM world, as evidenced by the growing popularity of VM farms, hardware support for virtualization, and controlled "turnkey" solutions, like MS's VirtualPC images for testing browser compatibility and the TurnKey set of appliances.

As others have said, your issues are probably due to insufficient hardware or sub-optimal configurations.

Development environment runs slower than normal (host OS is windows XP so memory is limited)

• This should not be noticeable. XP vs. Windows Vista or Win7 is a marginal comparison. I would check the amount of physical RAM allocated to the VM.

Switching between DEV machine and Email/Office machine is a pain, simple things like cut and paste are made harder. This is less efficient from a usability perspective.

• There are VM-specific optimizations/configurations that can make these tasks seamless. I would consult your VM maintenance staff.

Mouse in particular doesn't seem to work properly using VMWare player or RDP.

• Again, should be seamless, but consult VM staff.

Need a separate login to Dev/Test network/domain

• I would see this as a business decision: your company could obviously set up virtual machines with the same domain poicies as your own personal workstation, but may have other (big brother?) purposes for forcing you to login separately.

As far as using VM's as an agent of control, I think there are better solutions, like well-designed authorization controls around the production machines. There's nothing like paper trails to make people behave themselves.