A hypervisor is one of two main ways to segment a physical machine into multiple virtual machines; the other significant method is to use containers. A hypervisor segments the hardware by allowing multiple guest operating systems to run on top of it. In a container system, the host operating is itself divided into multiple containers, each running a virtual machine. Each virtual machine thus not only shares a single type of operating system, but also a single instance of an operating system (or at least a single instance of a kernel).
Containers have the advantage of providing lower overhead (and thus increased virtual machine density), and are often more efficient particularly in high I/O environments. However, they restrict guest operating systems to those run by the host (it is not possible, for instance, to run Windows inside a container on a Linux operating system), and the isolation between virtual machines is in general poorer. Further, if a guest manages to crash its operating system (for instance due to a bug in the Linux kernel), this can affect the entire host, because the operating system is shared between all guests.
As a result the performance and maturity of a hypervisor is important to consider.
Considerations when selecting a hypervisor
Hypervisors are simply the software that segments the physical hardware to run workloads in the virtual machine. And while technically that is true, attached to the choice of hypervisor come four other considerations.
- In Flexiant Cloud Orchestrator’s case, the choice of hypervisor controls how the hypervisor is integrated with Xen, KVM and Hyper-V, Flexiant Cloud Orchestrator communicates directly with the physical server (in Flexiant Cloud Orchestrator terminology, a ‘node’), using an agent installed on the node. However, with VMware, we communicate with VMware’s own management plane, which in turn communicates with the VMware hypervisor, ESXi – incidentally that’s why we refer to the hypervisor as ‘VMware’ rather than ESXi. This means that VMware users can take advantage of the rest of the VMware ecosystem. However, it also means that VMware users must put in place the normal control stack associated with a VMware deployment with consequent implications for hardware requirements.
- There are commercial implications to software choices. For instance, some hypervisor choices will require chargeable software licenses (VMware and Hyper-V), whereas KVM and Xen are open source and are included within Flexiant Cloud Orchestrator. VMware produced the first enterprise virtualization software and remains a market leader in that segment, and thus has a brand that is relevant to licensee’s customers, whatever licensees may think of it. Microsoft gives favorable licensing terms to Windows operating systems running on Hyper-V.
- Different hypervisors have different degrees of guest and functionality support. For instance, Hyper-V’s support for Windows is (unsurprisingly) second to none. However, as KVM and Xen are more closely coupled to Flexiant Cloud Orchestrator, the variety of network support options is greater on these hypervisors. Apart from guest OS integration, the two main areas affected by hypervisor choice are network functionality and storage functionality.
- There’s the breadth and maturity of Flexiant Cloud Orchestrator’s integration with the hypervisor concerned.
As a result, selecting a hypervisor is a multifactorial decision. After all, if one hypervisor always turned out best in all situations, we would not have provided support for four.
Read our white paper to see the analysis of four hypervisors. Download now.