5. VM sprawl: Originally, virtualization was a big hit simply for consolidating physical servers -- and thus reducing power demands and heat output. But because of the ease with which virtual machines can be deployed, organizations may find that while they have reduced the number of physical devices, the number of virtual systems to be managed has exploded. "One of the biggest gotchas out there is [virtual machine] sprawl," says John Humphreys, a program director at IDC. "We see this again and again: customers that before virtualization had 500 servers each with one image on them, for example, after virtualization all of a sudden have 700 images they're trying to manage." The best way to avoid that kind of sprawl is to plan virtual machine life cycles, recovering virtual instances that are no longer being used, he says.

6. Licensing costs: Just as companies may be haggling with independent software vendors that set license fees based on CPU usage over pricing on multicore servers, they also may find surprises when it comes to licensing in virtual environments. "Software licenses may be a barrier," says John Enck, a research vice president at Gartner. "You may want to run an application in a large, virtualized server, but the license may be written to apply to the physical processor cores in the machine. So if, for example, you move such an application from a two-way server to a four-way virtualized server, your software license costs may increase -- even though the software is only using two processors in the virtual environment."

7. Stuck on storage: Because many of the candidates for virtualization were on distributed x86 systems, it's easy to forget how the more centralized architecture of virtual resources can impact things. Storage, for example, should get a close look because in many cases virtual resources will all access a shared storage-area network (SAN). "Some companies may buy a certain type of storage array and they may not consider the workload that the VMware environment is going to put on it and it ends up being that that array just can't handle it: too much throughput, too much I/O," Xcedex's Payne says. "If that array goes down and has an issue on the SAN every single virtual machine is going to be negatively effected, meaning they're probably going to crash, they're probably going to get corrupted and it's going to be a really bad experience." National Semiconductor's Seif says storage concerns should be a priority when planning a virtual environment. SAN storage "is essential to reap the benefits of [business continuity/disaster recovery], allowing shifting workloads for optimizing uptime/performance and better scaling of guests to hosts," he says. "The amount of storage -- shifting from operating system, software and data on local server hard drives to SAN capacity -- can add up very fast, 40GB per host for us, and without a solid tiered storage strategy, it can eat up very expensive SAN storage very quickly."

8. Virtual roadblocks: With AMD and Intel servers running side-by-side in many data centers, some companies may think mobile virtual machines can be moved across any x86 hardware, but that's not the case. "The question people are struggling with is, 'As I move these [virtual machines] around, one, do I have to have similar hardware,'" says IDC's Humphreys. Today, VMware virtual machines can't move between Intel- and AMD-based systems, says Raghu Raghuram, vice president product and solutions marketing at VMware. "Our vmotion technology allows you to migrate a running application from one physical box to another, but the processors in those boxes have to be the same: so you can move from AMD to AMD or from Xeon to Xeon," he says. "It's because of the difference in processor architectures and the behavior of certain instructions. It's a problem that will get solved over the longer term."