Virtualization's dirty little secrets

Gotcha No. 1: You may not get the hardware savings you expect

One of the great ironies of server virtualization is that many people expect the technology to save them boatloads of money from the outset when, in fact, it often costs them more. That's because server virtualization demands two things: shared storage and some new servers that are powerful, richly configured, and equipped with hardware memory chips from the likes of AMD and Intel.

Even if you already have these souped-up servers, you're still not out of the woods. Server interoperability issues stymie many virtualization journeys. "You can't mix AMD and Intel platforms together in the same [VMware] ESX cluster," says Chris Wolf, an analyst at the Burton Group. "You cannot move a virtual machine between them without restarting."

The same goes for a storage area network, or SAN. Not every SAN supports a virtualized environment. Also, existing network bandwidth may not be sufficient to handle the needs of a growing number of virtual servers. This means you'll likely end up spending money on new servers, switches, and other tech gear. Even worse, upgrade costs can offset nearly all the initial savings from decommissioned servers, says Matt Prigge, a consultant and Test Center contributor.

When the server virtualization wave began to crest, industry watchers thought that the server market would be in a lot of trouble. After all, virtualization allows people to consolidate many applications onto fewer servers -- preferably existing ones. And they were partly right: Gartner believes that virtualization reduced the x86 server market by 4 per cent in 2006.

But it soon became apparent, the Test Center's Dineley says, "that you needed to strictly standardize on hardware for your virtual farm." Thus the server market remains strong: Some 8 million servers were shipped worldwide last year, a 6.7 per cent increase from the year prior, according to IDC.

Most people tackle hardware standardization and server virtualization slowly, usually when servers are due for retirement. They dabble in noncritical areas such as print servers before moving on to e-mail applications and enterprise databases. "It's a rolling-thunder approach," says John Humphreys, an IDC analyst. "We'll start to see the impact on [server] unit growth two, three, or four years down the road, as more people virtualize."

Gotcha No. 2: Getting the right staff experience is a challenge

IDG Research Services surveyed 464 participants late last year about their virtualization experience. The biggest challenge? Forty-four per cent of respondents said inadequate skills and training was the most difficult hurdle, followed by software licensing issues, performance and scalability challenges, and complexity.

So don't expect the IT staff to have all the answers to virtualization from the get-go. It'll take at least a month to gain an accurate understanding of current server workloads, given weekly and monthly spikes, before deciding which servers can be virtualized. In small companies with only a handful of IT folks, you may need to hire -- surprise! -- a pricey consultant to conduct capacity planning.

A small company also may not have the necessary SAN expertise or, for instance, capability to mesh Cisco switches and VMware's complex virtual networking stack. "Virtualization draws together so many different aspects of networking, server configuration, and storage configuration that it requires a well-seasoned jack-of-all-trades to implement successfully in a small environment," Prigge wrote in a "virtual" case study for the Test Center that's chock full of insight about challenges ranging from pricing and products to technical and skills requirements.

Larger companies don't have it easier, either. Getting a lot of people in disparate teams -- server, storage, business continuity, security -- on the same page is a feat, especially since they traditionally don't talk to each other very much. All of them, though, need to be educated about virtualization. If there's a problem with an application, for instance, an administrator must know where virtual machines exist throughout the server farm so that he doesn't reboot a server and unwittingly take down all the virtual machines on it.