2005 was a training year for the x86 virtualization race just around the corner, or rather, the quarter. At present, virtualization is primarily associated with carving one physical computer into multiple independent virtual systems. Virtualization is also providing a mechanism for helping shops that, overnight, watched their 1U rack boxes bloom into four-way servers, enabling them to carve up server resources into units of one or two CPUs each so they can be managed in a familiar way.
The introduction of Windows XP and Windows Server 2003 x64 Editions precipitated the greatest need for x86 virtualization. Many Windows applications, including Microsoft's own, can survive only in a 32-bit universe. Virtualization mocks up that smaller universe, yet allows 64-bit applications to run natively, albeit more slowly, thanks to the overhead of the virtualization runtime.
Did we say "more slowly"? We meant to say "a lot more slowly," a fact that explains why x86 virtualization has never been a must-have. Turning one speedy Xeon into two or three Pentium Pro-grade systems doesn't grab the imagination. If hardware-accelerated virtualization features that Intel and AMD will bake into their CPUs in 2006 live up to our hopes, virtualization will be far more commonplace.
Beyond the world of Linux under Windows and Windows under Windows is another level of technology -- enterprise virtualization -- that has very little in common with the hosted variety. Embodied in VMware's ESX Server and VirtualCenter, enterprise virtualization pools CPU, memory, networking, storage, and application resources.
Ordinarily, when you buy a new rack server, you load it with a static software image and assign it a fixed, likely permanent role. With enterprise virtualization, adding a rack server adds that new server's internal resources to an enterprisewide pool that's shared among all tasks and which you provision and reprovision to suit you. In addition to the fine-grained load balancing and ad hoc clustering that the solution brings to mind, relocating a server to another building on campus (or even to a partner's site) is reduced simply to pointing and clicking or working on a few lines of script code. The actual server can live anywhere. And the disk storage that each virtual server sees as local can be pulled together from multiple sources on the network.
When someone calls you to request a new server, you sit down at your desk and build a server or cluster that matches his or her requirements before you hang up the phone. If a demanding application bogs down others sharing the same server, you pick up its virtual machine instance, while it's still running, and drop it onto another physical server with more available resources. Users have no idea that SAP has just teleported down two floors. All they see is that it's running smoothly again, without missing a beat.