1

In Tanenbaum's Modern Operating Systems, fourth edition, about virtualization:

enter image description here

Are Virtualization without HW support, Virtualization with HW support, Paravirtualization, and Process virtualization exclusive between each other? (The way how the table is constructed seems to imply that.)

But I guess the first two are exclusive to each other, but each may overlap with the latter two (but I am not sure)?

How shall we understand the difference and relation between the four? Thanks.

2
  • As an aside, that chart contains an error. Either Hyper-V and KVM are both Type 1 hypervisors or Type 2 hypervisors. An argument could be made either way, but the arguments are exactly the same for both. Of course, when most people say "Type 1" and "Type 2" these days they don't really mean the original definitions. Commented Mar 14, 2015 at 2:44
  • Indeed, at least for KVM, the whole point was that OS services and hypervisor services would be one and the same, because why implement a memory manager, I/O scheduler and task scheduler in the hypervisor kernel, if you already have world-class implementations in the OS kernel anyway? Commented Mar 16, 2015 at 0:56

1 Answer 1

2

Paravirtualization means that the virtualized system knows that it is being virtualized and thus behaves differently than it would on real hardware, e.g. calling into the hypervisor instead of using some emulated device.

This is completely orthogonal to whether or not the (para-)virtualization is assisted by hardware. For example, Hyper-V with a normal guest is hardware-accelerated virtualization, Hyper-V with an "enlightened" guest is hardware-assisted paravirtualization.

Personally, I would not call Wine a virtualizer. Wine is an emulator. A virtualizer virtualizes something which is there, an emulator emulates something which is not there. Wine emulates the Windows ABI and API on Unix, where it does not exist. In fact, Wine orginally stood for "Windows Emulator", the meaning was later changed to "Wine is not an emulator" to highlight the fact that it does not emulate the x86 ISA (unlike QEmu, for example), but it obviously still does emulate the Windows ABI and API.

9
  • Thanks. (1) What do you mean by "orthogonal"? Has no relation? (2) What do you mean by "something which is there", and "something which is not there"?
    – Tim
    Commented Mar 14, 2015 at 2:58
  • @Tim It is possible for only part of an operating system to be paravirtualized. Full paravirtualization required that the guest operating system kernel be recompiled to be aware of the hypervisor, which worked but was kind of a pain to manage, on both ends. But it got around the problem of the lack of hardware support. These days, what you will see is that the guest OS isn't modified, but instead of it talking to emulated SATA disks and network adapters using the same device drivers as on physical hardware, it will use device drivers for virtual hardware, such as the virtio drivers.. Commented Mar 14, 2015 at 3:44
  • @Tim Or the Hyper-V "enlightenments" which are just device drivers that talk directly to Hyper-V. In each case this is done because it results in significant performance improvements over emulated devices. Commented Mar 14, 2015 at 3:46
  • @Tim: By "orthogonal" I mean the usual common programming/computer science/algebra/science meaning of "independent, doesn't interfere with each other, can be freely composed with each other", as in "orthogonal CPU instruction set", "orthogonal features", "orthogonal concerns", etc. By "something which is there" and "something which is not there", I mean exactly that: a virtualizer virtualizes a resource that is there. I.e. an x86 virtualizer such as VMWare virtualizes an x86 CPU which exists in the PC. An emulator such as QEmu emulates a CPU which is not there, e.g. a SPARC CPU on a PowerPC. Commented Mar 16, 2015 at 0:50
  • @Tim: Wine doesn't virtualize the Windows ABI/API on Unix, because there is no Windows ABI/API on Unix, there is nothing to virtualize. It emulates the Windows ABI/API on Unix. The reason why it is called "WINE Is Not (an) Emulator", is because some people assumed that Wine would be slow because it emulates the x86 CPU, which it doesn't. It only emulates the Windows libraries. That's why it was renamed from the original "WINdows Emulator" to "WINE Is Not (an) Emulator", to combat this misconception. Commented Mar 16, 2015 at 0:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.