doc: "hypervisor" -> "Virtual Machine Monitor (VMM)"

[phip1611]

doc: "hypervisor" -> "Virtual Machine Monitor (VMM)"

In literature, especially those with a microkernel background, virtualization stacks
are terminologically (and functionally) split into two components: Hypervisor
(kernel-space) and Virtual Machine Monitor (VMM) (user-space).

This terminological distinction also makes sense in monolithic kernel space (such as
Linux/KVM), as the functionality is always distributed between kernel- and user-space.
So, this commit introduces "Virtual Machine Monitor (VMM)" in the docs and replaces
most occurrences of "Hypervisor". I think this to clarifies things.

It is unfortunate that "cloud-hypervisor" uses "hypervisor" in its name, although it
is just a VMM for KVM (and other Hypervisor backends).

Some in literature also refer to VMMs as device managers.

I didn't change the NixOS options. But one could deprecate microvm.hypervisor
in favor of microvm.vmm.

[astro]

I am aware of the issue. The documentation already mentions it. I guess we could also solve this by adding any non-KVM Hypervisor like Xen?

[phip1611]

Then I would refer to VMM/Hypervisor, such as QEMU/KVM or foo/Xen. In each case, I personally don't think it is correct to refer to a hypervisor and then name a VMM first

[astro]

Yet, both VMM and Hypervisor work together. They are not configurable independently here.

I would really like to merge this for correctness but I still fear that an acronym is less comprehensible than a very related term. Any ideas?

[phip1611]

very related term. Any ideas?

IMHO no one will be overwhelmed by the new terminology. I'm always in favor of "breaking changes" in code and documentation, when the motivation is correctness (in terminology). Further, I didn't change the NixOS module options yet.

I don't really see how this can create more confusion. Actually, it even might other people to be less confused and better understand what microvm.nix does. But that's my personal opinion. Your project, your decision :)

[6ncp]

To add another 2 cents... while new terminology might not be overwhelming, people could be annoyed when new words do not provide any new value. I also agree with @astro regarding the use of acronyms. And by the way, QEMU defines itself as "generic and open source machine emulator and virtualizer" which "may work with a hypervisor such as KVM, [...]" (https://www.qemu.org/docs/master/about/index.html). This goes beyond VMM functionality.
I suggest adding an explanation that

• hypervisor in microvm context refers to the code controlling VM operation, and
• all supported hypervisors rely on Linux/KVM base infrastructure.
  Thus it is pretty much impossible to add "complete" hypervisors like Xen or Hyper-V to the project. [Please correct me if I misunderstood something!]
  I understand that semantics can be different in particular communities or organisations. So what appears natural to you, @phip1611, might cause confusion for others. For example, KVM originally (don't know if it's still the case) consisted of the kernel module and a user space component for device emulation.

[phip1611]

Thanks for jumping into the discussion. The more I think about it, the more I have to accept the fact that neither definition is complete and generic enough nor can become the standard.

Perhaps, the better solution is to briefly define in a Terminology section what the important terms mean for a specific project. For example, in the context of microvm.nix, hypervisor refers to a virtualization stack based on user-space and kernel space components. This can be, for example, QEMU/KMV, Cloud Hypervisor/KVM, or VirtualBox/vboxdrv (not supported yet, I think). What do you think about a brief terminology section in the README instead, @astro?

[astro]

I like that