Microsoft and VMware accepted our invitation, but the open source virtualization vendors - Citrix (Xen) and Red Hat (Linux-based hypervisor) - were unable to participate because they are undergoing product revisions. That left us with a head-to-head matchup between Microsoft's Hyper-V and VMware's market-leading ESX.

The findings here focus on hypervisor performance. A second installment coming later this month will take usability, management and migration features into account.

The question of which hypervisor is faster depends on a number of factors. For example, it depends on how virtual machine (VM) guest operating systems are allocated to the available host CPUs and memory. It also depends on numerous product-specific limitations that can restrict performance.

That said, VMware ESX was the overall winner in this virtualization performance contest - where we were limited to running six concurrent VMs because of the combination of our server's processor cores and memory capacity, and the limitation of the hypervisors we tested. ESX pulled down top honors in most of our basic load testing, multi-CPU VM hosting, and disk I/O performance tests.

Microsoft's Hyper-V, however, did well in a few cases, namely when we used a special set of drivers released by Microsoft to boost performance of the only Linux platform Hyper-V officially supports: Novell's SuSE Enterprise Linux.

VM hypervisors are designed to represent server hardware resources to multiple guest operating systems. The physical CPUs (also called cores) are represented to guest operating systems as virtual CPUs (vCPU). But there isn't necessarily a one-core to one-vCPU relationship. The exact ratio depends upon the underlying hypervisor. In our testing, we let the hypervisor decide how to present CPU resources as vCPUs.

The operating systems "see" the server resources within the limitations imposed by the hypervisor. As an example, a four CPU-core system might be represented as a single CPU to the operating system, which will then have to live on just that CPU. In other cases, four CPUs may be virtualized as eight vCPUs, in a scenario in which quieter VMs aren't likely to frequently use peak CPU resources. Other constraints can be imposed on the VMs as well, such as those pertaining to disk size, network I/O, and even which guest gets to use the single CD/DVD inside the server.