Talk:Hypervisor

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

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

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

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

Improved Lead

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]

Article Needs Work

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]

Citations

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]

History

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]

KVM type 2 hypervisor

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]

Type 3 hypervisor

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:

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.
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

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]

Classification of kernel-based hypervisors

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.