Virtualization that is distributed on workstations or on a big central server for testing and documentation?

Question

We are contemplating a push for employing virutalization for our test and documentation group to help manage consistent test and documentation environments. We were looking at choosing either a couple really big central boxes that consolidated several VM instances or just making sure everyone had a lot of disk space and ran something like virtual box on every machine.

I am sure there must be folks who tried one or both of these configurations and can tell me what the pros and cons are of either approach?

Answer 1

We've done something similar, but ended up falling back to desktop-based virtualization solutions.

The pros are that you can control the detail level of your configurations and make sure they're standardized and upgraded in lockstep with our production machines.

The downside is that a late night Selenium run (as part of continuous integration on webapps) can take down an instance that other people might need, so you either need to give root access on the Dom0 to everyone and hope that your developers can fix things when they break, or an admin has to spend a nontrivial amount of time keeping the central box running. We did also try splitting instances out (one instance of each type per developer) but found that it was just as complicated to administer because each developer broke things in their own unique fashion.

Our current policy is to have developers working on Apple hardware because it can run both linux and windows DomU's under various products, and we haven't bothered to figure out how to run an OSX DomU if it's even possible on Wintel hardware.

Answer 2

I can give you my reasons for preferring a centralized/server approach.

• Quotas: allowing me/managers to group up VM users and allot them resources that they can distribute among projects/VMs as needed
• Centralized view: lets me spot trends in how quickly we're going to need to buy more ram/servers
• Backup: much easier for me to manage server backups than workstations
• Shared pool: the money spent on server hardware will see higher utilization, I believe, than workstations (particularly in flex time orgs). Those will sit idle when people are on vacation.

I also feel that you get more bang for your buck out of higher end servers vs. workstations, but that may just be a gut feeling.

We do have a couple of hearty VM-churning laptops, primarily used by:

• Professional Services: it's a godsend to to haul a test environment to the customer's site
• Sales Demos

Answer 3

The answer, of course, is "it depends".

If you are running something like VMWare Workstation or using VMWare Player at the workstation because each user needs their own instance, then each running instance of the VM has to be a unique copy. Since local disk is always faster than network disk, you might as well copy the VMs to the individual workstations. This means the end user has more control over the VMs and can stop/kill them if they get hosed.

If you are running them on a central server because you need to strictly control the contents of the VM, AND you have some kind of extra-reliable fileserver like a NetApp or something, then I like to put them on the file server (either over iSCSI or NFS) and run them like that. This way if the VM server dies, your VMs are not stranded on the local disk of a server that is broken. (I presume that your extra-reliable fileserver has some form of 7x24, "it-is-broken-make-it-go" level of support contract.)

I've done it both ways depending on what the goal was.

Answer 4

We do test/devel VMs on workstations, rather than centralised VM servers. The main benefits are better developer control (reboots, fiddling, etc), better isolation (if a dev does something really stupid, the worst that can happen is that they melt their own workstation's CPU into glass), and the fact that there's otherwise all that hardware just sitting there under people's desks doing nothing (green computing, and all that)...