Introduction to virtualization
Every organization used to have physical servers. In most cases, they followed best practices and one server was dedicated to one application. This often led to wasted resources because the application didn’t actually need all the central processing unit (CPU) and random access memory (RAM) it was given, so those resources would sit idle. At the same time, the organization was paying for power and cooling for a server that wasn’t necessarily doing anything at the moment.The amount of time it took to stand up a new server could be an issue for projects that were time-sensitive. With each physical server, you had to rack it, cable it, configure it, and install software on it. Provisioning new servers for large projects could take weeks to months, especially if multiple teams were involved.
Virtualization was a game changer. Instead of buying individual smaller servers to run single applications, an organization could purchase bigger, more powerful servers to run a hypervisor of some kind that would, in turn, run multiple virtual servers, referred to as virtual machines (VMs). By purchasing larger servers to run the smaller workloads, organizations were able to save on power and cooling costs. They were also able to reduce the amount of time needed to go to market, because the virtualization administrator was typically the one who would spin up the server operating system in a VM, set up the networking, and perform the basic configuration tasks like assigning IP addresses and other necessary steps.
Virtualization really streamlined the process for system administrators and organizations to be able to build servers quickly in response to the needs of other teams for projects or for expanding the existing capacity to support applications. It also simplified recovery efforts when configured properly because VMs on a failed host could be transferred to another host.
You sometimes hear hypervisors referred to as hosts and virtual machines referred to as guests. If you run into this terminology, don’t let it confuse it. These terms are used across all types of virtualization technologies.
Type 1 and Type 2 hypervisors
Before diving into the difference between Type 1 and Type 2 hypervisors, make sure you understand what a hypervisor is. The hypervisor is essentially a process that allows you to create, run, and manage VMs.The hypervisor is ultimately responsible for presenting resources to the VMs that are running on it, including CPU, RAM, networking, and storage.
Most of the hypervisors let you overprovision VMs, meaning that you can assign resources that are not necessarily available. This may work for you if your workloads are very small, but if there are spikes in the workloads, or if VMs take too many resources, then the hypervisor could become starved for resources, which could impact all your VMs that are running on that hypervisor. Do not over-provision your VMs.
Type 1 hypervisors
Type 1 hypervisors are also referred to as bare-metal hypervisors. This is because the software for the hypervisor can run directly on the host system’s hardware. Type 1 hypervisors provide the best performance and security of the hypervisors, but some of them are more complex that others to set up.Here are some examples of the more common Type 1 hypervisors:
- Microsoft Hyper-V
- VMware ESXi
- Oracle VM Server
- KVM
- Citrix XenServer
Type 2 hypervisors
Type 2 hypervisors are referred to as hosted hypervisors. They require an operating system to be able to install and run. Type 2 hypervisors are usually easier to install and configure, but they’re less secure and not as performant as Type 1 hypervisors because they don’t have direct access to the host system’s hardware.Here are some examples of the more common Type 2 hypervisors:
- Oracle VirtualBox
- VMware Workstation
- VMware Fusion