You can't spell hypervisor without "hype."

One of the most frequently asked questions about Cloud Computing regard the necessity of hypervisors. I believe most reasonable individuals agree that while they are not absolutley NECESSARY, for most instances, they certainly make CC economically feasible.

My intent here, is not to run down the rathole of "which is the best hypervisor?" The answer to that, as well as most emotionally-charges questions is "it depends." My intent is, however, to examine how the needs of Cloud Computing may differ from those of the traditional Data Center where server (and eventually client)virtualization is concerned.

There is no question of who rules the Corporate Data Center. While VMware's absolute dominance of overall share has been dented (in part by wide deployments like Amazon, which can skew the statistics) drilling down by excluding Public or Government Clouds, will show VMware ESX (if various versions) as the 800 lb. Gorilla of server virtualization inside the firewalls.
Why then would Amazon choose to go with a wild card like Open Source Xen ? The answer is simply, because the needs of a hugely scalable publicly-available multi-tenant platform are far different then even the largest in-house Corporate Data Center, even if its owners choose to call it a "Private Cloud."

An in-house Data Center typically has a much higher ratio of administrators to servers (or VMs) than a public Cloud Provider.) They also view their servers as strategic resources, and less like a commodity of bits to be created, manipulated and destroyed. A "private" admin usually knows the functions, eccentricities and characteristics of the apps running on servers. Tweaking and tuning (even with the assistance of techniques like Dynamic Workload Balancing) are part of the job. The mature features of a product like VMware vSphere reflect that heritage, and meet those needs quite handily. vSphere meets them SO handily, in fact, that no other hypervisor, commercial or otherwise can hope to go head-to-head in a feature war with VMware, no matter how hard they try.

In a pure "Infrastructure as a Service" (Iaas) or even "Platform as a Service" (Paas) environment, users typically do not have granular control over the virtualization platform. They are renting CPU, Storage, I/O, etc. by the day (or minute) as a commodity, and the resources they are obtaining are highly abstracted from the physical environment. This is what Cloud is supposed to be. Paying huge salaries for the "care and feeding" of "commodities" is so 20th century. The question becomes one of trading granular control and its advantages for low-cost and flexibility.

With that in mind, do you really care if the 500 servers you just charged on your MasterCard are running on vSPhere, KVM, Open Source Xen or XenServer ? Do you care if your VMs can migrate uninterrupted across storage platforms of among hosts with various CPU steppings? You shouldn't. And more than likely, your Cloud Provider does not want to put a lot of time into thinking about that kind of data center minutiae either. You Cloud Provider want to perfrom the minimum amount of administration necessary to meet whatever SLA you may have agreed upon.
When it comes down to performance, hypervisor partisans will argue the merits of Hardware-Assist and Paravirtualization vs. Binary Translation and memory-over commit techniques. At the end of the day, if you step back, one will realize that they all do a very creditable job regardless of the underlying technology. While one hypervisor may favor small Windows workloads, and another Linux running more resource-intensive apps, when you get to Cloud scale, you start to again see the distinction between the "high-touch, custom" flavor of IT provided by the Corporate Data Center vs. the "low-cost, commoditized" version big Cloud Providers offer.
The folks running the Clouds are more likely discussing utilization of their assets with regard to profitability. Cloud Computing, as much as it comprises a number of technologies, at the end of the day, is also a business model.
One area where hypervisor choice does come into play is the question of migrating VMS from Private clouds to a Public facility (whether for creating a Hybrid, or for "Cloudbursting", or handling atypical peak loads." Besides security, portability of VMs is just about number 2 on a lot of CIO "worry lists." If you are a VSphere user internally, will you be better served by finding a Public provider who can load your VMDK files directly, or would taking a V2V (Virtual to Virtual) conversion to another supported format allow you to use a less-expensive provider taking advantage of Open Source cost-savings? There are plenty of free conversion tools, as well as commercial offerings liek Novell's Platespin which can convert (with varying degrees of success) among virtual disk formats supported by various hypervisors.

I suppose each entity will need to make that decision on their own in the short term. I suspect it won't be too long before the market sees an opportunity for a "universal VM translator" specifically designed for the Cloud and can scale accordingly. Once this happens, I think the days of high-priced virtualization solutions will be numbered.

It is interesting to not that the folks at Eucalyptus are planning on supporting ESX before making the alterations necessary to support Citrix XenServer (when they already have Open Source Xen and KVM nailed.) They say they are waiting for XenServer to gain more market share, and that the differences in Citrix's proprietary APIs prevent that offshoot of Xen from being easily addressed.