Yesterday we talked about the fact that IBM had single handedly created the world of virtualization. The single biggest innovation that drove virtualization was the creation of the hypervisor.
Recall that when IBM wanted to run additional operating systems on their mainframe computers there were some limitations with the supervisor code on the hardware and its ability to support a single instance of the operating system. The way IBM tackled the problem was to add an additional layer to the architecture to provide abstraction for the operating systems. Since the new layer ran atop the supervisor it was termed the “hypervisor.”
All Hypervisors are not created equally. In fact there are 2 distinct possible types of hypervisor. The types are called simply “Type 1” and “Type 2.”
When we talk about hypervisors it is essential to remember that they were contrived in a world where the PC, the Windows Operating system, and the modern client server terminology that we now take for granted did not exist. In todays world the supervisory code that IBM used back in the day would likely be called a Hardware Abstraction Layer or HAL for short. This makes even more sense when we start to talk about the 2 different types of hypervisors. Each type of hypervisor has a name that equates to the number of Hardware Abstraction Layers (HAL’s) present in the architecture for that type of hypervisor.
I can see you scratching your heads so lets get some more details.
Type 1 (or native, bare metal) hypervisors run directly on the host's hardware to control the hardware and to monitor guest operating systems. A guest operating system thus runs on another level above the hypervisor.
Type 2 (or hosted) hypervisors Run within a conventional operating system environment. With the hypervisor layer as a distinct second software level, guest operating systems run at the third level above the hardware.
The big elephant in this discussion that everyone tries to ignore is the fact that when you use a type 2 hypervisor which effectively includes the hardware HAL beneath the Host operating system and the Hypervisor HAL that runs in the form of software emulating hardware for the guest operating systems above the host operating system there is going to be a HUGE performance degradation to the guest operating systems. Now depending on what we are doing with that guest operating system that decrease in performance may be meaningless or it may be a deal breaker.
If I am using a type 2 hypervisor to run a guest operating system for the purpose of running a legacy application that just wont work on the current version of the OS then the likelihood is that a Type 2 hypervisor solution will be just fine. If the application hosts an infrastructure workload then all bets are off. Since the beginning of type 2 hypervisors at Microsoft the stance has been no support for infrastructure workloads running in type 2 hypervisor environments. That has not changed nor will it change unless someone out there makes a major discovery that allows significant improvement of performance on a multi-Hal environment, and frankly speaking I just don’t see that happening……Ever!
I know some of you are saying… “What exactly is an Infrastructure workload?”
It’s a good question. An infrastructure workload is nothing more than a workload that is based in a database. So Active directory, Exchange, SQL, DNS, DHCP, WINS, and Sharepoint would all count as Infrastructure workloads. Don’t run them in type 2 environments!
The last word. Window Virtual Server 2005 R2 is a type 2 hypervisor. Don’t run your infrastructure workloads there either!
So where are you supposed to run your infrastructure workloads.
Type 1 hypervisors would be the best choice.
Homework : Make a list of Type 2 hypervisor products that you use and put the reasons why you use them.
Next time we will talk about the why’s and how’s to use Windows Virtual PC (Microsoft’s current Type 2 hypervisor.)