Virtual Architect

Controlling End-User Sprawl

End users can contribute to virtual machine sprawl by using readily available, free downloads. Here are a few simple steps to head off problems before they begin.

• By Danielle Ruest and Nelson Ruest
• 05/01/2009

The power of guest operating system virtualization is undeniable; because of this, many organizations are taking advantage of it to move to a more dynamic infrastructure. The key to this power is the fact that virtual machines (VMs) are nothing but a set of files in a folder somewhere in your data center. Moving physical workloads to VMs liberates them from the traditional constraints of end-user-facing workloads.

But with agility comes the potential for disruption. VMs are easy to create; all an end user needs is access to two key tools.

The first is the virtualization engine. With the likes of freely downloadable offerings such as Microsoft Virtual Server, Microsoft Virtual PC, VMware Server and Sun's VirtualBox, users can run their own virtualization engine. These are all easily installed on any desktop or server and simply require administrative permissions to use. In addition, users who have access to custom hardware can even download production hypervisors such as VMware ESXi, Microsoft Hyper-V Server and Citrix XenServer, all of which are also free.

A second tool they need is OS installation files, also very easy to obtain because most OS vendors make them readily available, at least in evaluation format.

The use of these two tools together can lead to desktop VM sprawl, especially in environments where end users have local administrative rights to corporate machines. Users might decide they'd like to have their own VMs for whatever purpose. This has the potential to cause problems down the line.

For one thing, end users usually lack the skills required to construct stable and secure OSes. Most tend to follow the prompts and install the default OS settings, often leading to unsecured OSes running in VMs in your internal network. As you can imagine, this can lead to all sorts of issues -- unpatched machines, unsecured services such as mail transfer agents, machines that might be infected with viruses -- all running in the network and potentially causing disruption of IT services to other users.

The best way to avoid this is to be proactive. Begin by identifying any end user that may have a requirement for running a VM of his or her own. This will usually include scientists, developers, testers, application packagers or Web page designers that need to test their output with several browsers. It might also include users that need to create components that normally should not be on their production system.

Then create a plan to support these needs:

First: Determine which virtualization tool to support in production. One recommended approach is to use VMware Player, which is free. Because users need the ability to run but not necessarily create VMs, using this option instead of a complete virtualization engine preserves IT department prerogatives.

Second: Create standardized and secure VM templates for each of the OSes end users require and provide them with a copy. They can personalize and use it however they need.

Third: Teach users how to work with VMs, including how to protect them by making duplicates and how to use the snapshot feature in the virtualization tool to capture changes.

Fourth: Create a support policy for VM use that indicates how you will assist users if issues arise. In its simplest form, the policy should state that if an end user breaks a VM, they should get another copy of the original template and re-initiate the process.

Making end-user VM use a matter of policy has many advantages. End-user requirements are met, VM sprawl is held in check and IT has much better control of the use of VMs, which means no surprises.