The Myth of Type I and Type II Hypervisors

The Myth of Type I and Type II Hypervisors
This has been something that has bothered me for a while that I have never gotten a chance to articulate. In the virtualization community, the terms "type-1" and "type-2" hypervisors get thrown around a lot--often carrying different meanings. Lately, "type-2" is being used as a derogatory term suggesting that a virtualization solution is "lesser" than a true "type-1" hypervisor.

The most common definition of "type-1" and "type-2" seem to be that "type-1" hypervisors do not require a host Operating System. In actuality, all hypervisors require an Operating System of some sort. Usually, "type-1" is used for hypervisors that have a micro-kernel based Operating System (like Xen and VMware ESX). In this case, a macro-kernel Operating System is still required for the control partition (Linux for both Xen and ESX).

The whole argument of micro-kernel vs macro-kernel hosts is a different blog post (just as a spoiler, I think one can make a better argument for macro-kernel hypervisors). I want to focus, instead, on why we have these terms and what they really mean.

Virtualization theory really started with a paper from Gerald Popek and Robert Goldberg called Formal Requirements for Virtualizable Third Generation Architectures. The paper is a mathematical proof of the architectural requirements to allow virtualization. It is very terse and I don't expect most people have read it. The paper focuses on implementing full virtualization on native hardware and focuses on things like whether privileged instructions are trappable. It was written in 1974 and Operating Systems were not actually all that common back then. Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine.

As best as I can tell, the terms "type-1" and "type-2" originate from a paper by John Robin called Analyzing the Intel Pentium's Capability to Support a Secure Virtual Machine Monitor. This paper was Robin's master thesis at the Naval Postgrade School. There are two versions of the paper available, the actual master's thesis and a condensed version for USENIX 2000.

This paper is really an application of the Popek/Goldberg proof to the Pentium architecture. A few points were missed, but it does a rather good analysis of why the Pentium architecture did not satisfy the Popek/Goldberg requirements for virtualization. Now, some folks at VMware have made a rather compelling case that this is in fact incorrect because the Popek/Goldberg proof does not eliminate the possibility of using dynamic translation. At any rate, Robin makes a distinction between "type-1" and "type-2" VMMs. The reason for the distinction is simple. When discussing "type-1" VMMs that access hardware directly, the set of requirements to enable Secure Virtualization entirely depends on the hardware. When discussing "type-2" VMMs, however, you do not have direct access to hardware so the requirements to enable virtualization are actually at the Operating System interface. A true "type-2" VMM is just a process in an Operating System and is not capable of accessing hardware directly.

The important point to take away here is that all modern virtualization solutions (except for unaccelerated QEMU maybe) are technically "type-1" VMMs according to Robin. The things commonly cited as "type-2" VMMs like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware. This makes all of these solutions "type-1" VMMs. What's more important though is that the distinction of "type-1" and "type-2" has absolutely no bearings on performance, robustness, or any other qualitative factor. It is merely a distinction made when attempting to formulate a proof about whether virtualization is possible or not. It starts to lose meaning too when an Operating System is capable of supporting a true "type-2" VMM (which arguable, the KVM interface in Linux enables). Does that mean that Linux is a "type-1" VMM and QEMU using the KVM interface is a "type-2" VMM? How can the same solution be both though? IMHO, the introduction of the term "type-2" was really a mistake on Robin's part perhaps as a misunderstanding of the section of the Popek paper regarding recursive virtualization. That's just speculating though. The distinction really just doesn't make much sense in my mind.

So if you've made it this far, I'll hope you agree that these terms really have no practical meaning and will join me in refraining from using them in the future :-)

POSTED BY ANTHONY LIGUORI AT 1:42 PM
13 COMMENTS:

John said...
I must admit I never knew everyone was
mis-using the terms, interesting. For
me the distinction is really about one
thing: if the "control" OS is rebooted,
do the VMs continue to exist in any
meaningful way?

This makes LDOMs (and Xen, if they
hadn't failed at the implementation) type-1, and KVM etc. type-2. I suppose it's kind of unfortunate the meaning has changed but I'm sure you know by now that complaining about shifts in meaning is always, always, futile :)

5:25 PM
Anthony Liguori said...
It really depends on how you define "control" OS. With KVM, the host is Linux. With Xen, the host is a custom microkernel. You certainly could have an extremely small host userspace with KVM and launch a single guest with access to all hardware and the ability to launch other guests. This guest would be then be the "control" OS and you could, in theory, reboot it.

So it's more a configuration issue than anything. It's not something fundamental to the VMM technology.

6:10 PM
John said...
Well, if you modify any project enough
it can be turned into something else. I'm
not sure that's meaningful.

8:55 AM
Anonymous said...
Anthony -

Delineating type 1 vs. type 2 hypervisors goes at least as far back as Robert Goldberg's Harvard Thesis in 1973 - Architectural Principles of Virtual Computer Systems. I am not sure I see how you can come to the conclusion that the difference is insignificant.

From a security perspective, I think there are pretty important differences. If you compromise a host OS (type 2), you can gain access to both VMs and hypervisor processes and code. While this may be possible in a type 1 environment, there is a significantly smaller attack surface to contend with.

Pete Lindstrom

2:09 PM
Anthony Liguori said...
Hi Pete,

I think you've just highlighted the biggest misconception around--that's Type I and Type II have anything to do with any real product out there.

Goldberg differentiated between hardware requirements to allow full virtualization and then the requirements of a software interface. This has nothing to do with "hypervisors".

What you're really trying to argue is that virtualization is better done with a micro-kernel than a monolithic kernel because of the inherently smaller TCB. I won't get into the whole micro/macro kernel debate here but suffice to say that that argument is totally independent of virtualization.

8:10 PM
Anonymous said...
Anthony -

I'm not sure I understand how you've interpreted Goldberg - his definition is pretty basic and your concerns seem like semantic ones.

I do agree, however, that things are ambiguous today (and poised to get even more ambiguous in the near term)with diffs btwn type I/II and also VMM/hypervisor for that matter.

It seems pretty straightforward to me - in one scenario, user processes are running on the physical system at the same level as hypervisor processes with no need to "escape" a VM first. In the other scenario, user processes run in one or more VMs.

While the micro/macro argument can be independent of virtualization, it is not clear to me how the reverse could be true, so I still assume that it is applicable.

I welcome a better distinction or way to talk about these differences with more clarity, but have only seen type I/II and VMM/hypervisor used in academic literature and the trade press.

I don't see how you can say it doesn't matter from a security perspective, especially given all the attention that being "isolated" gets (my interpretation of Type II means there is user space that doesn't get isolated the same way).
I believe this is highly applicable to use cases where virtual machines are being deployed/used on the client-side.

Pete Lindstrom

11:59 AM
Anthony Liguori said...
Hi Pete,

It seems pretty straightforward to me - in one scenario, user processes are running on the physical system at the same level as hypervisor processes with no need to "escape" a VM first. In the other scenario, user processes run in one or more VMs.

When you say, "user", you mean that some user can log into the host and run arbitrary things. However, it's very important to realize that there's no requirement with something like KVM that the host have anything more than a single init process than launches guests. In this case, there would have to be a control partition that interacts with this "single init process" but no other process could actually launch in the host environment.

So in this model, I believe KVM qualifies as a "Type I" hypervisor by your definition. However, how can KVM be both a Type I and Type II hypervisor?

This all gets back to my original point. The terms "Type I" and "Type II" are really meaningless outside the context of discussing the formal requirements for full virtualization of a hardware/software system. This is, in my opinion, a strict interpretation of the Goldberg/Popek paper and the only one that makes sense.

8:36 PM
Anonymous said...
Hi, Anthony -

I think we are disconnecting. It is rare with any sort of classification system not to have exceptions. I am unfamiliar with KVM but am fine with exceptions.

What I was hoping for was a useful alternative to Type I/II that addresses the security differences I described. I suspect security isn't your bag, which is fine since this was a random hit on a google search for me.

Note that one of your colleagues from IBM uses these types in his extensive collection of attributes about the main players over at it20.com.

I won't bother you any more.

Regards,

Pete Lindstrom

5:31 PM
Mindframe said...
Type 1 should be BIOS level hypervisor, and not at Linux kernel which is an OS kernel too. If someone programmed a BIOS level hypervisor, then it is an absolute Type 1 hypervisor. I think product such as Xen (runs on linux) is just like a hypervisor software runs on Windows Server 2008 Core or just plain Windows Server Hyper-V which is on TYpe 2.

10:03 AM
Anonymous said...
As far as this security debate about gaining access to type-2 hypervisors and being able to control both the host and all guests is what I find semantic since if you gain controlling access to a type-1 hypervisor you can have the same level of control. As stated, currently accepted definitions of a type-1 hypervisor still includes software running in a read/write fashon, which means it can be hacked and controlled, meaning that such a scenario is not limited to only type-2 hypervisors, nor makes such access any more a threat when comparing types of hypervisors.

5:55 PM
Anonymous said...
Hmm ... I found this post after reading the wiki entry on hypervisors and was curious about the practical reasons for making a distinction between both types of hypervisors. From what I can see, the distinction is at best of academic interest?

2:27 PM
Rackmount LCD said...
KVM fits the definition of a Type 1 hypervisor for two reasons: I'st- it runs in kernel mode on bare metal and uses a hardware virtualizer. II'nd, KVM guests spend almost all their time running in direct execution mode.

11:53 PM
organic pet food said...
This has been so enlightening. I´ve discovered your website today and i´m enjoying it so much. It is full of smart advices!

7:59 PM

Reference:
http://blog.codemonkey.ws/2007/10/myth-of-type-i-and-type-ii-hypervisors.html
http://mrpointy.wordpress.com/2009/05/12/is-kvm-a-type-1-or-a-type-2/
http://forums.freebsd.org/showthread.php?t=21104
http://twit.tv/show/floss-weekly/130