A hypervisor is a function that abstracts -- isolates -- operating systems (OSes) and applications from the underlying computer hardware. This abstraction allows the underlying host machine hardware to independently operate one or more virtual machines (VMs) as guests, allowing multiple guest VMs to effectively share the system's physical compute resources, such as processor cycles, memory space, network bandwidth and so on. A hypervisor is sometimes also called a virtual machine monitor (VMM).
A hypervisor would be used by someone who wants to consolidate space on a server or run multiple isolated applications on a single server. Hypervisors are commonly supported in virtualization software such as VCenter Server.
Types of hypervisors
Hypervisors are traditionally implemented as a software layer -- such as VMware vSphere or Microsoft Hyper-V -- but hypervisors can also be implemented as code embedded in a system's firmware. There are two principal types of hypervisor: Type 1 and Type 2 hypervisors. Type 1 hypervisors are deployed directly atop the system's hardware without any underlying operating systems or other software. These are called "bare-metal" hypervisors and are the most common and popular type of hypervisor for the enterprise data center. Examples include vSphere or Hyper-V. Type 2 hypervisors run as a software layer atop a host operating system and are usually called "hosted" hypervisors like VMware Workstation Player or Parallels Desktop. Hosted hypervisors are often found on endpoints like personal computers (PCs).
What are hypervisors used for?
Hypervisors are important to any system administrator or system operator because virtualization adds a crucial layer of management and control over the data center and enterprise environment. Staff members not only need to understand how the respective hypervisor works, but also how to operate supporting functionality such as VM configuration, migration and snapshots.
The role of a hypervisor is also expanding. Storage hypervisors, for example, are used to virtualize all of the storage resources in the environment to create centralized storage pools that administrators can provision, without having to concern themselves with where the storage was physically located. Today, storage hypervisors are a key element of software-defined storage. Networks are also being virtualized with hypervisors, allowing networks and network devices to be created, changed, managed and destroyed entirely through software without ever touching physical network devices. As with storage, network virtualization is appearing in broader software-defined network or software-defined data center platforms.
In the early to mid-1960s and 1970s, the earliest forms of hypervisors were created. In 1966, IBM released its first production computer system -- the IBM System/360-67-- which was capable of full virtualization. IBM also began production of their CP-40 system in 1967. This system ran off a modified S/360-40 system, which provided virtualization capabilities. This system also allowed multiple user applications to be run concurrently, which was not possible before. The Control Program/Cambridge Monitor System (CP/CMS) operating system by IBM was released in 1968 and lasted through the 1970s.
In 1970, IBM released System/370, which would add support for virtual memory two years later in 1972. Since then, virtualization has been a feature in all later systems. Around this time, more community members began using open source projects to further develop virtual systems with hypervisors.
1985 saw IBM introducing the PR/SM hypervisor, which could manage logical partitions. During the mid-2000s, more operating systems such as Linux, Unix and Windows began supporting hypervisors. Around this time, hypervisors began growing with better hardware, cost and consolidation abilities. In 2005, vendors began supporting virtualization of x86 products.
Hypervisors provide several benefits to the enterprise data center. First, the ability of a physical host system to run multiple guest VMs can vastly improve the utilization of the underlying hardware. Where physical (nonvirtualized) servers might only host one operating system and application, a hypervisor virtualizes the server, allowing the system to host multiple VM instances -- each running an independent operating system and application -- on the same physical system using far more of the system's available compute resources.
VMs are also very mobile. The abstraction that takes place in a hypervisor also makes the VM independent of the underlying hardware. Traditional software can be tightly coupled to the underlying server hardware, meaning that moving the application to another server requires time-consuming and error-prone reinstallation and reconfiguration of the application. By comparison, a hypervisor makes the underlying hardware details irrelevant to the VMs. This allows any VMs to be moved or migrated between any local or remote virtualized servers -- with sufficient computing resources available -- almost at-will with effectively zero disruption to the VM, a feature often termed live migration.
VMs are also logically isolated from each other -- even though they run on the same physical machine. In effect, a VM has no native knowledge or dependence on any other VMs. An error, crash or malware attack on one VM does not proliferate to other VMs on the same or other machines. This makes hypervisor technology extremely secure.
Finally, VMs are easier to protect than traditional applications. A physical application typically needs to be first quiesced and then backed up using a time-consuming process that results in substantial downtime for the application. A VM is essentially little more than code operating in a server's memory space. Snapshot tools can quickly capture the content of that VM's memory space and save it to disk in moments -- usually without quiescing the application at all. Each snapshot captures a point-in-time image of the VM which can be quickly recalled to restore the VM on demand.
Containers vs. Hypervisor
Containers may, at first glance, seem similar to hypervisors. However, hypervisors isolate operating systems and applications from the underlying computer hardware, whereas containers are a type of software that can virtually package and isolate applications for deployment. Unlike hypervisors, containers are designed to share access to an operating system kernel without the traditional need for VMs. As an example, a hypervisor can run multiple operating systems, but a container running on Linux can only run Linux because the container is making use of the Linux kernel.
In comparison, containers have more overhead and are more efficient, but at the cost of not being able to run other operating systems. As an example, an individual can use many more containers on a server than with a kernel-based VM (KVM).
Kubernetes vs. Docker
Kubernetes is another containerization software used in managing Linux containers across private, public and hybrid cloud environments. Kubernetes is an open source system created by Google, originally launched in 2015. Kubernetes can automate the scheduling, deployment, scaling and maintenance of containers across clusters of nodes. Kubernetes and Docker are both popular, stable services. Whatever each customer chooses, they should be met with near-equal product standards.
The hypervisor security process includes ensuring the hypervisor is secure throughout its lifecycle, including during development and implementation. If an attacker gains unauthorized access to the hypervisor, VMM or the software which orchestrates the virtual environment, then that attacker would then have access to every VM under the hypervisor's control. The attacker could then gain access to any and all the data stored in each VM. Other possible vulnerabilities include shared hardware caches, the network and potential access to the physical server.
Common security practices for hypervisors include limiting the users in a local system, limiting attack surfaces and keeping systems updated. Organizations should use additional monitoring and network security tools when regarding hypervisor security. System administrators should also set restrictions to remote and console access to the hypervisor. Type 1 and Type 2 hypervisors deploy in environments differently, so users should secure each hypervisor type with different security techniques.