Choose Wisely
Virtualization, by its very nature, is going to introduce overhead when comparing an application running natively on hardware with the same application running in a VM on that same hardware. In our tests this rate varied by application, but it was generally less than 10 percent, with lows of 6 percent and highs of 20 percent.
We ran a number of application-based tests on two Dell PowerEdge 2850 servers. Both systems were configured identically, with dual, dual-core Intel Xeon processors, 2 GB of RAM and a three-drive RAID array. The Xeon processors included Intel VT (Virtualization Technology), which provides microcode optimizations for CPU virtualization. We ran a baseline set of tests for three applications, Microsoft's Exchange Server 2003, SQL Server 2005 and IIS (Internet Information Services), using a combination of free and commercial tools, including Microsoft's Exchange Server 2003 Load Simulator (LoadSim) and SQLIOSim as well as Borland's SilkPerformer 2006 R2 (for more on our tests, see "Tester's Notes").
Our test environment differed from what enterprises would typically run in that we didn't have dedicated storage subsystems, such as a SAN (storage area network), for data storage for specific applications. A SAN doesn't just simplify data storage and data management for applications like Exchange, it also prevents the contention for resources that arises when the OS and application need access to virtual memory as opposed to needing access to disk for data storage. With a dedicated storage subsystem, that contention is minimized.
In terms of our results, the impact of running applications against the local drive subsystem would have little bearing on our tests of the overhead of VMware's VI3 on basic application performance. The overhead of ESX Server is confined to system memory and processing power. In tests where we ran multiple VMs simultaneously, the impact again depended on whether the applications required continuous access to disk.
In all likelihood, companies looking to use virtualization to consolidate servers will still see some contention for disk resources, regardless of whether data resides on the server or a SAN. Say you consolidate multiple file and print servers on a single box using VMs and store the files in the VM or store all the data from all the servers on a single SAN. In either case, the VMs will be accessing the data from the same shared resource.
The performance overhead of virtualization can be viewed against two basic assumptions: IT is going to use virtualization to fully utilize servers the company owns, or a company is looking to consolidate existing servers onto newer hardware. For the purposes of baseline testing, we used the former assumption of maximizing server utilization.
Under the full-utilization scenario, IT divides up memory, in theory because existing memory isn't being fully used. Say you notice that an application running on dedicated hardware uses only part of the memory and processing capacity of that server--perhaps 512 MB out of 2 GB and 25 percent of 2.8 GHz. Migrating this application to VMware's ESX Server lets you dedicate that 512 MB and 700 MHz to the application and still have memory and processing power available. Therefore, in our tests, we divided our 2 GB of memory based on the needs of the applications running on the VM instances. SQL Server requires a minimum 1 GB of RAM, for example, while Exchange Server 2003 will run with 512 MB of RAM.
VMware has memory-page sharing technology that lets IT overcommit physical memory for VMs. This memory-page sharing lets VI3 allocate at least twice as much virtual memory as there is physical memory when running the same OS on VMs running on the same hardware. This is useful in situations in which you want to consolidate a number of low-use apps, such as file and print services, running on individual servers. A single server could run a dozen VMs because the likelihood of all these systems requiring processing power and memory at the same time is small, and even when requests exceed resources, slowed performance wouldn't be an issue.
Architecturally, VMware's ESX Server 2.0 uses a stripped-down version of Linux to host VMs, then abstracts each VM's hardware through a common virtual BIOS and virtual hardware drivers. In our initial tests, we measured the performance costs of these two layers, but also factored in less memory being available to each virtual machine; ESX Server requires roughly 200 MB of memory.
The good news? VMware's done a good job creating an environment that will let apps run at a high level of performance without much of a penalty caused by generic hardware drivers and a Linux-based VM hosting environment. We were able to operate relatively demanding apps, such as Exchange Server 2003 and SQL Server 2005, with just a 6 percent performance penalty. Both the LoadSim test for Exchange (see "Virtualization Hit: Exchange" in the image gallery) and the SQLIOSim test (see "Virtualization Hit: Virtual Hardware" in the image gallery) for SQL Server have heavy disk read and write components, so our results illustrate that apps that rely on drive performance may not suffer too greatly, provided there isn't contention for disk access among VMs.
The area where we saw substantially slower performance was in our intranet performance test, which used SilkPerformer 2006 to test the performance of IIS. We saw performance drop off 18 percent in hits per second, and 20 percent in kilobits per second (see "<Virtualization Hit: Intranet" in the image gallery). Unlike the SQL Server and Exchange tests, here we saw the price paid for moving from a robust system with 2 GB of RAM to a VM with only 512 MB. With less memory, system performance suffered considerably more than with more disk-bound tests.
