Hypervisors
Virtualization relies on a special type of software, known as a hypervisor, which creates the virtual hardware for devices. There are many different varieties of hypervisors, including open source and commercial. Some hypervisors run as standalone applications on Windows, MacOS, or Linux, whereas other hypervisors are installed as the underlying operating system itself. Regardless, all hypervisors have something in common: they use software to create the illusion of physical hardware.
Hardware is essentially programming instructions baked into copper and silicon chips. With enough skill, you could recreate that programming in software. Now imagine that you learn how to recreate all the hardware in a computer’s motherboard as a series of software programs. You continue the process with its graphics card, network card, and even its hard drive. You now have a collection of programs that, when connected together, have the appearance of a physical computer, but it is executing as software. This is virtualization, and you have just created your first set of virtual hardware. Each instance of virtual hardware is called a virtual machine, or VM.
The virtual hardware is such an elaborate and convincing illusion that you can actually install a real operating system within the VM, and it works as if it had been installed on physical hardware. The operating system (OS) installed within the VM is often referred to as a guest OS to differentiate it from the operating system of the underlying physical computer, which is called the host OS. To help you remember these terms, just think of the hypervisor as a host to a number of house guests called VMs.
The hypervisor provides the VM, and therefore the guest OS, access to the physical CPU and RAM resources as well as access to a virtual disk that the guest OS believes is a real, physical hard drive. Optionally, you may also provide a virtual network card that also appears real and that will give the VM access to the network. With few exceptions, the guest OS will behave in the same way it would if it had been installed directly on physical hardware. To make the illusion complete, some hypervisors include special device drivers that you can install within the guest OS to gain performance improvements and access to features that would be otherwise impossible on physical hardware.
Hypervisors are able to host multiple VMs, each running its own guest OS and applications. Each VM has its own virtual hardware that the hypervisor manages and keeps isolated and independent of the other VMs. The hypervisor serves as a resource traffic cop in that it manages how each VM accesses and consumes the physical hardware resources, such as CPU, RAM, networking, and storage. To the rest of the world, these VMs appear as isolated and independent as individual physical servers. Also, despite the magic of virtualization, VMs still cannot communicate telepathically with one another. So, if you want them to talk to each other, you will have to install virtual network adapters in the VMs and configure their networking as you would do with your physical servers.
There are two types of hypervisors: Type 1 (bare metal) and Type 2 (hosted). Both types can host VMs; however, they have very different use cases. Type 2 hypervisors, which you will learn about first, look and feel like any other application that you may run on your laptop. Type 1 hypervisors typically requires dedicated hardware and are installed as that machine’s operating system, making them more commonly found in data centers than in home networks.
Diagram. Type 1 and Type 2 hypervisors.
Type 1 hypervisors, also called bare- metal hypervisors, differ from Type 2 hypervisors in the way they are installed. Remember that a Type 2 hypervisor, such as VMware Workstation, is installed as an application within your existing computer or laptop operating system. Type 1 hypervisors, such as VMware ESXi or the open-source KVM hypervisor, are operating systems that natively run virtual machines and are intended to be installed on a dedicated bare metal server. This is a significant difference because, as an operating system, the Type 1 hypervisor has complete access to the underlying hardware of the physical computer, which alleviates the performance penalty that Type 2 hypervisors commonly face.
Another important difference between the hypervisors is in how you access and manage the host and the guests. Type 1 hypervisors present very little information to the console screen of the host computer. While there may be a limited user interface for troubleshooting the hypervisor directly, all administration is typically performed from another computer, such as your laptop. On your laptop, you would direct a web browser to the IP address or hostname of the hypervisor to access its web-based administration portal.
To make this a bit clearer, consider the earlier example of using VMware Workstation to run a Windows Server VM on your laptop. The hypervisor was just an application installed on your Windows 10 laptop that you were logged in to and that was able to directly interact with the settings of Windows 10 (your laptop), VMware Workstation (the hypervisor), and Windows Server (the VM). Conversely, if you have installed a Type 1 hypervisor on a computer, you can see the basic troubleshooting interface on its monitor but must use a web browser on a separate computer to administer the hypervisor and the VMs running on it.
Also, remember that VMs are typically connected to the network just like any other physical computer. Users that need to connect to a VM typically are not granted access to the hypervisor configuration portal; rather, they are given an IP address or hostname for the VM that they need to connect to.
A Type 2 hypervisor, sometimes referred to as a hosted hypervisor, is installed as an application on personal computers or laptops. This allows the user to run different VMs that all share the laptop or computer’s hardware resources. This allows you to run operating systems within a VM other than what was natively installed on your computer or laptop. For instance, imagine that you are an application developer creating a new application that will run on Windows Server. Your laptop is running Windows 10, which is similar to Windows Server but may not be close enough for you to properly test your application. You could install a Type 2 hypervisor, such as VMware Workstation or Microsoft Hyper-V, to allow you to run VMs on your laptop. This would allow you to create a VM running Windows Server and then log in to the VM to install and test your application.
In another example, you are a student with a laptop running MacOS. One of your classes requires you to gain familiarity with Linux, but you do not want to purchase a second computer. Again, you could install a Type 2 hypervisor for MacOS, such as VMware Fusion or Parallels Desktop, which would allow you to create and run a Linux VM on your laptop.
One important aspect of Type 2 hypervisors is that they are installed and run as a regular application on your computer or laptop. This means two things: first, the hypervisor is competing for hardware resources with all the other running applications on your computer; and second, the hypervisor does not have direct and unrestricted access to the physical hardware but instead must send all your VM’s hardware requests through your computer’s operating system. Both issues can lead to degraded performance within your VMs, but slower performance may be far more desirable than buying and carrying around separate computers.
Virtualization relies on a special type of software, known as a hypervisor, which creates the virtual hardware for devices. There are many different varieties of hypervisors, including open source and commercial. Some hypervisors run as standalone applications on Windows, MacOS, or Linux, whereas other hypervisors are installed as the underlying operating system itself. Regardless, all hypervisors have something in common: they use software to create the illusion of physical hardware.
Hardware is essentially programming instructions baked into copper and silicon chips. With enough skill, you could recreate that programming in software. Now imagine that you learn how to recreate all the hardware in a computer’s motherboard as a series of software programs. You continue the process with its graphics card, network card, and even its hard drive. You now have a collection of programs that, when connected together, have the appearance of a physical computer, but it is executing as software. This is virtualization, and you have just created your first set of virtual hardware. Each instance of virtual hardware is called a virtual machine, or VM.
The virtual hardware is such an elaborate and convincing illusion that you can actually install a real operating system within the VM, and it works as if it had been installed on physical hardware. The operating system (OS) installed within the VM is often referred to as a guest OS to differentiate it from the operating system of the underlying physical computer, which is called the host OS. To help you remember these terms, just think of the hypervisor as a host to a number of house guests called VMs.
The hypervisor provides the VM, and therefore the guest OS, access to the physical CPU and RAM resources as well as access to a virtual disk that the guest OS believes is a real, physical hard drive. Optionally, you may also provide a virtual network card that also appears real and that will give the VM access to the network. With few exceptions, the guest OS will behave in the same way it would if it had been installed directly on physical hardware. To make the illusion complete, some hypervisors include special device drivers that you can install within the guest OS to gain performance improvements and access to features that would be otherwise impossible on physical hardware.
Hypervisors are able to host multiple VMs, each running its own guest OS and applications. Each VM has its own virtual hardware that the hypervisor manages and keeps isolated and independent of the other VMs. The hypervisor serves as a resource traffic cop in that it manages how each VM accesses and consumes the physical hardware resources, such as CPU, RAM, networking, and storage. To the rest of the world, these VMs appear as isolated and independent as individual physical servers. Also, despite the magic of virtualization, VMs still cannot communicate telepathically with one another. So, if you want them to talk to each other, you will have to install virtual network adapters in the VMs and configure their networking as you would do with your physical servers.
There are two types of hypervisors: Type 1 (bare metal) and Type 2 (hosted). Both types can host VMs; however, they have very different use cases. Type 2 hypervisors, which you will learn about first, look and feel like any other application that you may run on your laptop. Type 1 hypervisors typically requires dedicated hardware and are installed as that machine’s operating system, making them more commonly found in data centers than in home networks.
Diagram. Type 1 and Type 2 hypervisors.
Type 1 hypervisors, also called bare- metal hypervisors, differ from Type 2 hypervisors in the way they are installed. Remember that a Type 2 hypervisor, such as VMware Workstation, is installed as an application within your existing computer or laptop operating system. Type 1 hypervisors, such as VMware ESXi or the open-source KVM hypervisor, are operating systems that natively run virtual machines and are intended to be installed on a dedicated bare metal server. This is a significant difference because, as an operating system, the Type 1 hypervisor has complete access to the underlying hardware of the physical computer, which alleviates the performance penalty that Type 2 hypervisors commonly face.
Another important difference between the hypervisors is in how you access and manage the host and the guests. Type 1 hypervisors present very little information to the console screen of the host computer. While there may be a limited user interface for troubleshooting the hypervisor directly, all administration is typically performed from another computer, such as your laptop. On your laptop, you would direct a web browser to the IP address or hostname of the hypervisor to access its web-based administration portal.
To make this a bit clearer, consider the earlier example of using VMware Workstation to run a Windows Server VM on your laptop. The hypervisor was just an application installed on your Windows 10 laptop that you were logged in to and that was able to directly interact with the settings of Windows 10 (your laptop), VMware Workstation (the hypervisor), and Windows Server (the VM). Conversely, if you have installed a Type 1 hypervisor on a computer, you can see the basic troubleshooting interface on its monitor but must use a web browser on a separate computer to administer the hypervisor and the VMs running on it.
Also, remember that VMs are typically connected to the network just like any other physical computer. Users that need to connect to a VM typically are not granted access to the hypervisor configuration portal; rather, they are given an IP address or hostname for the VM that they need to connect to.
A Type 2 hypervisor, sometimes referred to as a hosted hypervisor, is installed as an application on personal computers or laptops. This allows the user to run different VMs that all share the laptop or computer’s hardware resources. This allows you to run operating systems within a VM other than what was natively installed on your computer or laptop. For instance, imagine that you are an application developer creating a new application that will run on Windows Server. Your laptop is running Windows 10, which is similar to Windows Server but may not be close enough for you to properly test your application. You could install a Type 2 hypervisor, such as VMware Workstation or Microsoft Hyper-V, to allow you to run VMs on your laptop. This would allow you to create a VM running Windows Server and then log in to the VM to install and test your application.
In another example, you are a student with a laptop running MacOS. One of your classes requires you to gain familiarity with Linux, but you do not want to purchase a second computer. Again, you could install a Type 2 hypervisor for MacOS, such as VMware Fusion or Parallels Desktop, which would allow you to create and run a Linux VM on your laptop.
One important aspect of Type 2 hypervisors is that they are installed and run as a regular application on your computer or laptop. This means two things: first, the hypervisor is competing for hardware resources with all the other running applications on your computer; and second, the hypervisor does not have direct and unrestricted access to the physical hardware but instead must send all your VM’s hardware requests through your computer’s operating system. Both issues can lead to degraded performance within your VMs, but slower performance may be far more desirable than buying and carrying around separate computers.