Talk:Hypervisor

This is the talk page for discussing improvements to the Hypervisor article. This is not a forum for general discussion of the subject of the article.

Add new text under old text. New to Wikipedia? Welcome! Learn to edit; get help. Start a new topic Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Article policies Neutral point of view No original research Verifiability

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing: Software Mid‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Mid-importance).

Archives

Archive 1

I changed the lead to make it clearer to non-specialists, and more accessible to the (large majority of) people who know nothing about IBM mainframes. I propose removing the warning about the introduction, as per the poster above.

Dan Shearer (talk) 13:20, 11 October 2010 (UTC)Reply

The body of the article needs to be improved to reduced confused concepts, especially under "UNIX and Linux servers" and "PC and Desktop Systems". There is no reference to Linux paravirt_ops , no reference to Xen being a portable hypervisor (it runs on three architectures, at least) and need to explain where the concept popularly described as "Linux is the Hypervisor" fits in. Dan Shearer (talk) 13:27, 11 October 2010 (UTC)Reply

Update: I couldn't find the PowerPC port for Xen in the source tree, sure enough, it's been pulled: see http://wiki.xensource.com/xenwiki/XenPPC . Xen ARM still exists but I'm not convinced about how much life is in the project. Ok, so Xen is more portable than ported, not a lot more to say :-)

Dan Shearer (talk) 13:39, 11 October 2010 (UTC)Reply

Re "UNIX and Linux servers" and "PC and Desktop Systems".

I think it would be clearer if these sections were considered in terms of x86 architecture platforms rather than as server and desktop.

What do you think?

--SimonBramfitt (talk) 19:16, 19 January 2013 (UTC)Reply

I have removed the following citations from the introduction

^ Don Skiba, author of this addition, was the instigator for the RPQ in 1965 ^ Documentation for IBM RPQ E880801

this is anecdotal evidence only

--SimonBramfitt (talk) 00:12, 30 January 2013 (UTC)Reply

I'm deleting

==History==

The term "hypervisor" was first used in 1965, referring to software that accompanied an IBM RPQ for the IBM 360/65. It allowed the model IBM 360/65 to share its memory: half acting as an IBM 360 and half as an emulated IBM 7080. The software, labeled "hypervisor," did the switching between the two modes on split-time basis. The term hypervisor was coined as an evolution of the term "supervisor," the software that provided control on earlier hardware.

I've not found anything that confirms the claim that hypervisor was coined in 1965. The text has no valid citations (see previous section) and is contradicted by Dave Tuttle above.

--SimonBramfitt (talk) 19:14, 30 January 2013 (UTC)Reply

Question: The article says, ``in a series of disputed and bitter battles, time-sharing lost out to batch processing through IBM political infighting, and VM remained IBM's "other" mainframe operating system for decades, losing to MVS." I don't see any links to other Wikipedia articles that talk about these battles, nor any citations. This must be written up somewhere--where? Mcswell (talk) 17:01, 7 September 2016 (UTC)Reply

In the article KVM is listed as a Type 1 hypervisor, but BHyVe that's exactly the same as KVM for FreeBSD is listed as a Type 2. That arrises the question of why is KVM listed as a Type 1 hypervisor?

Also VirtualBox and VMware Workstation work in the same way as KVM, but are also listed as Type 2, so either everything is Type 1 (and we loose the Type 1/Type 2 differentiation), or KVM is moved to Type 2. — Preceding unsigned comment added by Roger.pau (talk • contribs) 14:02, 10 July 2013 (UTC)Reply

Hello, Roger. Welcome to Wikipedia.

Please sign your messages by adding ~~~~ at the end.

I am not familiar with KVM and BHyVe but I am perfectly sure that VirtualBox and VMware Workstation are both hosted (type 2) hypervisors. That said, I am afraid your second paragraph is a bit of false dichotomy. Someone familiar with the subject needs to investigate and find out the correct answer.

Best regards,

Codename Lisa (talk) 15:04, 11 July 2013 (UTC)Reply

Hello, sorry for not putting the ~~~~ at the end.

IMHO KVM turns Linux into an hypervisor using exactly the same hardware mechanisms as VirtualBox turns Mac OS X into an hypervisor, VMware Workstation turns Windows into an hypervisor or BHyVe turns FreeBSD into an hypervisor (they all use the same x86 hardware virtualization extensions).

88.9.20.28 (talk) 11:57, 12 July 2013 (UTC)Reply

Hi. VirtualBox and VMware Workstation do not turn Mac OS X or Windows into hypervisors. They are hypervisors themselves. On Windows, they run in user space and killing their process ends the entire hardware virtualization chain. I have even seen and used VirtualBox as a portable app! They are textbook examples of type 2.

User:Jandalhandler has added further clarifications. Best regards, Codename Lisa (talk) 20:19, 12 July 2013 (UTC)Reply

Both VirtualBox and VMware Workstation load a kernel module that allows them to make use of the x86 processor virtualization extensions, and then they run a userspace program that is the device model emulation, and again this is just like KVM, that uses a kernel module to access the virtualization extensions and then runs Qemu in userspace to provide the device model emulation, if you kill the userspace Qemu process you effectively kill the VM.46.33.159.2 (talk) 14:14, 15 July 2013 (UTC)Reply

Hi. That is completely true. VirtualBox loads vboxdrv.sys, VMware Workstation loads vmx86.sys and Virtual PC loads vpcmm.sys. But a kernel driver still runs on top of HAL. In bare-metal hypervisor, however, HAL has to run on top of hypervisor, performing hardware abstraction as VMM sees fit, exposing what VMM exposes. And besides, these drivers don't do the bulk of virtualization task. Just imagine how funny would it be if VMware wanted to write everything in Native API.

But again, as I said before, I do not know anything about KVM. So, since I can't discuss it, I can't compare it either and this whole discussion is futile unless you wait for or solicit the aid of someone who knows.

Best regards,

Codename Lisa (talk) 21:55, 15 July 2013 (UTC)Reply

There's no official literature on what defines a Type 1 or 2 hypervisor as far as I am concerned. However, the fundamental concept is clear to everyone and evident from the figure in the wikipedia article Hypervisor. Furthermore, IBM has a publication that supports the concept and is available here: [1]. Based on all that, I think it is irrelevant if certain kernel modules make the base OS behave like a hypervisor; it remains the base OS and is not a hypervisor in the same sense that Xen or ESXi are today. I agree with Roger that KVM should be classified as a Type 2 hypervisor. I feel the article should clearly state this fact and the clarifications added recently are not enough. Franciozzy (talk) 14:29, 19 July 2013 (UTC)Reply

I think that there have been enough technical arguments to move KVM to Type 2 and remove the KVM note at the bottom of "Classification". If anyone has any doubts or technical arguments of why KVM should be a Type 1, please say so.Roger.pau (talk) 12:11, 22 July 2013 (UTC)Reply

Hi. It appears you are not fully aware how things work in Wikipedia. Although decisions on Wikipedia are made based on consensus (which is clearly absent here), core Wikipedia policies take precedence. There is a source that indicates there is – or have been – a dispute as to whether KVM is type 1 or type 2 hypervisor. According to the core policy of neutrality, we do not issue a verdict as to who is right of who is wrong. We report both significant points of view impartially, without commenting on them. So, sorry, no! What you suggest violates the NPOV policy. Best regards, Codename Lisa (talk) 15:36, 22 July 2013 (UTC)Reply

Hello, I would agree with you if there was a technical discussion here, but you (or anyone else) failed to provide any technical arguments on why should KVM be classified as a Type 1 hypervisor. Could you please point me to your technical argument on why we don't have a consensus regarding why KVM is not a Type 2 hypervisor? The only reference on why KVM is a Type 1 hypervisor is a Graduate Thesis which doesn't contain any kind of technical arguments on why KVM should be classified as a Type 1 hypervisor.Roger.pau (talk) 15:56, 22 July 2013 (UTC)Reply

Hi. I did not fail because I did not even attempt a discussion. (I refrained from discussing KVM.) That said, inserting material on articles based on technical discussions is not allowed in Wikipedia. The KVM has two sources. So, it should stay that way. A dissertation has all the qualities that is expected of a reliable source: Educated author, editorial oversight (academic oversight, to be accurate) and contents. (See WP:SCHOLARSHIP) If you have another source, present it, so we can cover it.

Best regards,

Codename Lisa (talk) 08:21, 23 July 2013 (UTC)Reply

this whole "type 1" and "type 2" situation is a mess. I've only had experience with Xen and KVM

Xen (supposedly type 1):

• boots a small kernel, based on a very stripped down version of a Linux kernel
• then launches the first VM, dom-0, which is used for administration
• launched VMs use the CPU virtualization extensions
• but not everything is done in the hypervisor. For example, there are qemu-dm processes inside the dom-0 which help the VMs access storage

KVM (type unknown, people don't agree even in this thread):

• boots a normal linux kernel
  • you might say that it's type 2 then -- but if the KVM module is compiled in then the virtualization capabilities are available from the get go and it's type 1?
• launched VMs use the CPU virtualization extensions
• in userspace there are qemu processes to manage storage / networking

the type 1 / type 2 distinction is

• neither clear (you can see in this thread and in the main article people not able to assign the KVM type)
• nor useful. In both cases the end result is that the CPU has the hardware extensions which help with actual execution of the code. And in both cases there's a userspace process helping with networking / storage. 88.148.156.203 (talk) 20:34, 20 February 2025 (UTC)Reply

Hi.

I am addressing a contribution by Vmdocker which I reverted today in accordance to WP:BRD. (I am hoping Vmdocker is seeing this.) It added a type 3 hypervisor to article but the contribution had the following problems:

1. It failed verification. In other words, the 1974 article by Popek and Goldberg did not say anything about a third type. As most people here know, this is a deal-breaker.
2. Even if a source can be found to assert that LXC is an L3 hypervisor, it is still the question of whether it is appropriate in this article. Hypervisor applies to full virtualization whereas LXC is a method of OS-level virtualization.

Best regards,
Codename Lisa (talk) 15:36, 28 August 2014 (UTC)Reply

Reference # 15 ("SubVirt: Implementing malware with virtual machines". University of Michigan, Microsoft.) link no longer works. This paper is publically available, but not (currently) from that URL. http://research.microsoft.com/apps/pubs/default.aspx?id=67911 is one place the paper is available(in HTML or PDF). A UM alum, 38.104.195.22 (talk) 18:20, 16 March 2015 (UTC)Reply

Fixed, thank you for pointing it out! — Dsimic (talk | contribs) 06:54, 26 March 2015 (UTC)Reply

Last paragraph of "Classification" section states "Linux's Kernel-based Virtual Machine (KVM) and FreeBSD's bhyve are kernel modules" however in both cases the code can be compiled directly into the kernels which would cause them to cease being kernel modules. As this is also what is done in OpenBSD (which no longer supports kernel modules) with its new kernel-based hypervisor, I suggest the wording is changed to "Linux's Kernel-based Virtual Machine (KVM) and FreeBSD's bhyve are kernel subsystems" as this seems more generic and correct. — Preceding unsigned comment added by 2001:1970:5C20:8901:4064:765F:56DD:917D (talk) 18:16, 1 May 2017 (UTC)Reply

According to the article on firmware, firmware is software. So I think listing firmware separately is redundant. Alfa-ketosav (talk) 16:11, 20 April 2026 (UTC)Reply