VMware Vs KVM
A hypervisor is a program, hardware, or firmware combination that constructs, executes, and manages virtual machines (VMs). The device running a hypervisor is call its host, while each VM on the host is know as a guest. A hypervisor provides the guests with a virtual operating platform that handles their operating systems (OSs). That enabling multiple operating systems to share virtualized resources on the same host.
One of the most significant reasons for a company to introduce hypervisors is its ability to share resources. But the variety of currently available hypervisors will question this decision process. A choice between VMware and Kernel-based Virtual Machine (KVM) often results in the selection of a hypervisor. VMware is a company name that designs a variety of hypervisors including the ESXi enterprise-class. KVM is a Linux kernel architecture that offers a hypervisor’s capabilities.
The following points of comparison can help organizations in need of a hypervisor choose between VMware and KVM.
Performance
Hypervisors can be divide into two categories, influencing their performance.
Type 1:
Type 1 hypervisors, also known as hypervisors of “bare metal,”. It run directly on the physical hardware, and each guest’s OS runs on top of the hypervisor. Typically, these hypervisors allow a few guests to control the hypervisor. Most enterprises use hypervisors Type 1.
Type 2:
A Type 2 hypervisor, also known as a host hypervisor, runs on the physical hardware inside an operating system. Every guest’s OS then runs atop the hypervisor. Desktop hypervisors are hypervisors typically of type 2.
Example:
Xen is probably the best example of a pure Type 1 hypervisor, although ESXi is clearly a Type 1 hypervisor because it is not an application install on an operating system. ESXi provides a kernel and other elements of the OS which are incorporate into the native operating system.
KVM’s classification is more difficult because it shares all forms of hypervisor characteristics. It is distribute as a Linux component, so a Linux user can start KVM from a command line or GUI. Such start-up methods make it appear as if the hypervisor is operating on the host OS, even though KVM is running on the bare metal.
The host OS provides a launch mechanism for KVM and creates a co-processing relationship with it, allowing KVM to share control with the Linux kernel over physical hardware. While operating on x86 hardware, KVM uses the processor’s virtualization instructions, allowing the hypervisor and all of its guests to run directly on bare metal. Most of the resource translations are done by physical hardware, so KVM meets the traditional criteria for a Type 1 hypervisor.
A Type 1 hypervisor should be equivalent to a Type 2 hypervisor, with all other factors equal. Type 1 hypervisors escape the overhead that a Type 2 hypervisor would experience when it asks the host OS for access to physical resources. Other factors however also play an important role in the performance of a hypervisor. ESXi, for example, generally takes more time to create and start a server than KVM. When running servers, ESXi also has slower performance, although this difference may be insignificant for typical loads.
Integration
The hypervisors use various methods to communicate with the physical hardware of the host. KVM uses a host-installed agent to communicate with hardware, while ESXi uses the control plane used by VMware to communicate with hardware. The process does offer the benefit of allowing ESXi to access other VMware products using this management plane. Nevertheless, ESXi also includes the use of the control stack of VMware, which may increase the hardware requirements.
Close integration with the host OS is the main reason why Linux developers usually choose KVM soon after its release in 2007. By comparison, until 2011, eight years after its initial release, Xen did not officially become a part of the Linux kernel. Linux developers are also more likely to use KVM, because it has been adopted by Red Hat and other Linux distributors preferably to other hypervisors. Illumos is an OpenSolaris-based open-source OS which also opted for KVM over other hypervisors when adding hardware virtualization support.
Complexity
A comparison between KVM and VMware also shows a significant difference in the size of the code base which affects the maintenance costs of a hypervisor. KVM was initially release to take advantage of processor extensions that allowed guests to be virtual without binary code translation. This origin meant that KVM’s first stable release was basically a lightweight virtualization driver, with just over 10,000 lines of code (LOC).
It is estimated that VMware has more than 6 million LOC, although this fact cannot be verified since its source code is not available to the public. This total does not directly affect performance, since VMware uses guest virtualization hardware extensions. Nevertheless, it never fully rewrote its original code, resulting in a more complicated code base than KVM.
Maturity
Both KVM and ESXi are both extremely mature and stable. KVM has been a part of the Linux kernel for more than a decade and since 2006 ESXi has been available to the public. However, since it is open source, KVM is more widely deploy and include in many packages like Redhat Enterprise Virtualization (RHEV). Even KVM supports more features than any other hypervisor.
Cost
KVM clearly wins over cost-based VMware. KVM is open source so no additional costs are incurred for the user. It is also distributed in several ways, often as part of an open-source operating system.
VMware charges a license fee, like ESXi, to use its products. It can do this because VMware was the first company to release virtualization software enterprise-class and is still the market leader in this segment. Hence, its brand is still important to end users of a market, regardless of what developers may think about it. An ESXi owner must also purchase a license to use vSphere, the cloud computing application suite VMware uses ESXi. Additional software licenses may be need which will increase the cost of implementing ESXi further.
In 2012, IBM carried out some calculations concerning total ownership costs (TCO) for KVM and VMware. These calculations showed that the TCO of the KVM was typically 39 per cent lower than that of VMware. Although the actual TCO will depend on site-specific factors such as operational setting and workload. The disparity in TCO indicates that cloud service providers are likely to want to incorporate KVM on at least one node, regardless of other factors to consider.
Scalability
KVM is more robust than VMware, primarily because vSphere has certain restrictions on the servers that it can handle. In addition, VMware has added a considerable number of Storage Area Networks (SANs) to support various vendors. This feature means VMware has more storage options than KVM, but it also complicates the storage support for VMware when it is scaled up.
Functionality support
Hypervisors vary greatly in the features they provide. Support for networking and storage is particularly important and is undoubtedly more important than any other aspect in addition to OS integration. It should not come as a surprise to hear that any other hypervisor does not suit the support of ESXi for other VMware products. By contrast, KVM offers more network support options than VMware does.
Conclusion
KVM is typically the most popular choice for users who are concerned about the operating costs of each VM. And who are less interested in features at the enterprise level. This rule applies specifically to cloud and host service providers, who are particularly sensitive to their server costs and densities. These users, particularly KVM, are highly likely to choose open source hypervisors.
Tight integration with the host operating system is one of the most common reasons developers choose KVM, especially those using Linux. Also, the incorporation of KVM into many Linux distributions makes it a convenient choice for developers. Also, KVM is more popular among users who don’t care about brand names.
