Sujet : Re: VMWARE/ESXi Linux
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.os.vmsDate : 03. Dec 2024, 17:10:25
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vinahh$598$1@reader2.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
In article <
vina48$3sjr$6@dont-email.me>,
Arne Vajhøj <
arne@vajhoej.dk> wrote:
On 12/3/2024 10:36 AM, Dan Cross wrote:
In article <vin68p$3sjr$4@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 11/28/2024 8:24 AM, Dan Cross wrote:
So Goldberg defined two "types" of hypervisor in his
dissertation: Types 1 and 2. Of course, this is an over
simplification, and those of us who work on OSes and hypervisors
understand that these distinctions are blurry and more on a
continuum than hard and fast buckets, but to a first order
approximation these categories are useful.
>
Roughly, a Type-1 hypervisor is one that runs on the bare metal
and only supports guests; usually some special guest is
designated as a trusted "root VM". Xen, ESXi, and Hyper-V are
examples of Type-1 hypervisors.
>
Again, roughly, a Type-2 hypervisor is one that runs in the
context of an existing operating system, using its services and
implementation for some of its functionality; examples include
KVM (they _say_ it's type 1, but that's really not true) and
PA1050. Usually with a Type-2 HV you've got a userspace program
running under the host operating system that provides control
functionality, device models, and so on. QEMU is an example of
such a thing (sometimes, confusingly, this is called the
hypervisor while the kernel-resident component, is called the
Virtual Machine Monitor, or VMM), but other examples exist:
CrosVM, for instance.
>
I think the relevant distinction is that type 1 runs in the
kernel while type 2 runs on the kernel.
>
Reinserted:
# If VSI created a hypervisor as part of VMS then if
# it was in SYS$SYSTEM it would be a type 2 while if it
# was in SYS$LOADABLE_IMAGES it would be a type 1.
Irrelevant; this is based on your misconception of what a type-1
hypervisor is vs a type-2.
No. They both run in supervisor mode. On x86, this is even
necessary; the instructions to enter guest mode are privileged.
>
That code does something that end up bringing the CPU in
privileged mode does not make the code part of the kernel.
>
To build on the VMS example the hypothetical type 2
hypervisor in SYS$SYSTEM could (if properly authorized)
call SYS$CMKRNL and do whatever. It would not become
part of the VMS kernel from that.
This isn't really reelvant.
Just like VMWare Player or VirtualBox running on Windows
is not part of the Windows kernel even if they do use CPU
support for virtualization.
They rely on existing OS services for resource allocation,
scheduling, memory management, etc, which is why they are
type-2 HV's and not type-1. Xen, Hyper-V, and ESXi implement
those things themselves, which is why they are type-1, and not
type-2.
Go back to Goldberg's dissertation; he discusses this at length.
^^^
Read this part again, Arne.
KVM runs in Linux not on Linux. Which makes it type 1.
Nope. KVM is dependent on Linux at this point. The claim that
it is a type-1 hypervisor is predicated on the idea that it was
separable from Linux, but I don't think anyone believes that
anymore.
>
It is the opposite. KVM is type 1 not because it is separable
from Linux but because it is inseparable from Linux.
Kinda. The claim is that KVM turns Linux+KVM into a type-1
hypervisor; that is, the entire combination becomes a the HV.
That's sort of a silly distinction, though, since the real
differentiator, defined by Goldberg, is whether or not the VMM
makes use of existing system services, which KVM very much does.
I wrote about this here, at length, several years ago. C.f.,
https://groups.google.com/g/comp.os.vms/c/nPYz56qulqg/m/vTDtsFNRAgAJPerhaps go review that post and read the associated references.
- Dan C.