Before we jump directly to the headline, let me explain one of the most important metrics of virtualization: VM density - the number of virtual machines running on a host. Virtualization is often used to reduce the hardware required to operate a data center, and the more servers one can consolidate on to a virtualization host, the fewer host systems one needs. This of course results in much lower operating costs due to fewer required software licenses, less energy consumed, considerably less space needed, and fewer administrators. So, in order to decide which solution is best for you, it's vitally important to be able to compare VM density among different virtualization solutions. One of the ways you can do that is with the industry standard virtualization benchmark, SPECvirt_sc2013. You may have heard of its predecessor, SPECvirt_sc2010, which was released in [of course] year 2010. And you may be aware that KVM quickly dominated the results produced with that benchmark earning the top score in every server configuration that has been used to produced results: 2, 4, and 8 socket systems.
SPECvirt_sc2010 has been a good representative workload, but like many benchmarks, its relevancy can erode over time as technology and user's actual workloads change. The IT industry is continually evolving, and newer benchmarks are needed to approximate the workloads that are relevant. The evolution of SPECvirt from sc2010 to sc2013 is an example of staying relevant. So, how is sc_2013 different? Three ways set it apart from sc_2010:
- Each virtual machine requires more resources. The workloads are used to simulate either more users or users with higher request rates. The resources a VM may need can be nearly six times compared to sc_2010. This was done to match what's happening in many data centers: many users are moving their more demanding workloads to be virtualized.
- Many of the VMs in sc_2013 have much higher variability in the resource usage. The workload load levels vary quite a bit more than sc_2010. This requires the hypervisor to react quickly and correctly, providing the right hardware resource to the right VMs at the right time.
- The idle VM is now a "batch" VM. On sc_2010, some of the VMs were simply idle, to represent some portion of VMs which were available, but not in use. Sc_2013 enhances that scenario by having periods for which the VM is idle, but also has periods that it must handle a batch processing job. You can think of these as servers which may have been idle all day, but perhaps processed "end-of-day" jobs which must be completed before the next day.
So, how well does KVM do with sc2013? Let's take a look at two results, one using IBM Flex System x240 server with Red Hat Enterprise Linux 6.4 with its Kernel-based Virtual Machine (KVM) hypervisor , and another using HP ProLiant DL380p Gen8 server with VMware ESXi v5.1 . Both systems under test are equipped with Intel E5-2690 processors, 256 GB of memory, and SSD for storage.
Care to guess how much higher the VM density was for IBM KVM solution?
No, even higher... 37% more VM density!
That is a "stop what we are doing and choose a different strategy" result. This IBM - Red Hat Enterprise Linux 6.4 with KVM solution consolidated 37 virtual machines, while the HP - VMware result only consolidated 27 VMs. Imagine the reduction in both hardware and virtualization licensing cost you could achieve by moving from VMware to KVM. Learn more about IBM open virtualization and KVM here.
Senior Software Engineer, IBM Linux Technology Center