As the field of virtualization developed, two overall classifications emerged: type 1 and type 2. As the products continued to mature, the distinctions began to blur. As a result, some terminology has begun to be used interchangeably even though it was originally meant for two very different things. A case in point is “Host Operating System” as opposed to “Parent Partition”. These terms are actually different and using the “wrong” one can sometimes lead to a heated debate. When it comes to terminology, the most important thing is ensuring that you and your audience know what you mean, even if the words may not be exactly right. However, there is never any harm in learning the history of your vocabulary.
Type 1 vs. Type 2
Hypervisors are divided into two overall archetypes. The distinctions are few, debatable, and shrinking, but are still more than matters of trivia. The type 1 hypervisor either is the kernel or is a part of the kernel. A “kernel” is software that runs “closest” to the hardware. It is in charge of managing system resources and how/if they can be accessed. It is the only piece of software that a system cannot run without. When a hypervisor is implemented at this level, it does not need to wrestle with standard applications for resources. The type 2 hypervisor is a “normal” application. Its access to resources is governed by the kernel and it has no greater or lesser say in terms of resource contention than any other application running on a given system.
Below are some graphics to help you visualize these differences. They are designed in layers. The hardware is the foundational layer, and everything else is built on top of it.
It should be fairly simple to see the differences between the two types. Keep in mind that these are simplistic diagrams and there are nuances that make them not entirely true, although they are accurate enough for this discussion. For instance, modern operating systems often run non-kernel functions inside something that could be called a “partition” even if there is only one “partition”.
Note: Regardless of how it is installed, whether it’s the free edition installed directly to the hardware or if it’s set up as a role from within Windows, Hyper-V is always a type 1 hypervisor. The action of enabling the role within a Windows installation is a deceptively simple change that masks a lot of in-depth and complicated changes that rearrange your installation so that Hyper-V is the kernel.
Which Term is Correct for Hyper-V?
For Hyper-V, there are very powerful reasons that either term is technically acceptable, although “parent partition” is probably the most correct. Consider the type 1 diagram above. Hyper-V runs in the kernel layer. During installation, all the files for Windows are placed into the same hard drive space as the Hyper-V kernel and are included in a shell partition that sits atop Hyper-V (the “shell” is a special application that allows the user to interact with the kernel, such as DOS and Windows Explorer). This partition is given particular privileges; most importantly, it has the greatest access to the kernel. This special relationship is what designates it as the “parent partition”. This seems so cut and dry that it’s tough to imagine why “host operating system” would be an acceptable term at all. It works because even though Hyper-V is part of the kernel, it is dependent upon drivers and other files within the parent partition for full operation. As such, it does not and cannot operate completely independently of that partition, which is the basis for calling it the “host operating system”. A more detailed visualization of any current Windows installation, with or without Hyper-V, would actually look a lot like the type 1 diagram. Without Hyper-V enabled, the largest difference is that there is only one “partition”. In contrast, some other type 1 hypervisors use a “monolithic” kernel in which almost everything the hypervisor needs is bundled into a single package. These aren’t entirely independent of their parent partitions either, as they still need a bootstrapper in order to start at all, have some reliance on configuration files, and of course they need a shell in order to be managed. As time goes on, the lines will continue to blur and the distinction between the two terms will become even less important. Now that you have a better understanding of what’s going on, feel free to use the term that makes the most sense to you.
Speaking of Terminology, Where Did “Hypervisor” Come From, Anyway?
From the hallowed halls dedicated to the black art around kernel design, there emerged a very special function called the “supervisor”. It is the job of the supervisor to manage the access of system resources by individual processes. In a single operating system environment, there is only one supervisor and any more would be extraneous. The term “hypervisor” was coined as a designator for the process that manages the supervisors.