I truly don't understand how someone could write this and not see the answer. I've long been bothered by this problem, but here the author manages to completely

I truly don't understand how someone could write this and not see the answer. I've long been bothered by this problem, but here the author manages to completely miss it: The very things we're trying to get out of hypervisors today are identical, or nearly so, to the things that we wanted to get out of operating systems. That is, what we call a "hypervisor" today is really just an OS. The author of this paper had all of the facts necessary to come to this realization: "The early time-sharing systems isolated users from other users. [. . .] The time-sharing system also isolates the system and hardware components from the unprivileged user." "The hypervisor provides the necessary isolation and controls guest resource use. Since the hypervisor exposes only a simple hardware-like interface to the guest, it is much easier to reason about what can and should happen than it is to do so with containers." Those two paragraphs are just the same things written in different ways: isolation of users from each other, hardware abstraction, and resource-sharing[1]. Those are the fundamental tasks of an operating system. If we call the operating system a "hypervisor"[2] and the user an "application", it makes no difference. Hypervisors have a place in allowing non-communicating users to run (different) existing kernels (and thus operating systems) on the same hardware. Great for VPS's. However, using them for multiple potentially cooperating (but not necessarily mutually-trusting[4]) applications is missing the point. Operating systems have all of the necessary tools (hardware hooks) to properly isolate different users ("applications"); if they currently don't do a proper job of it then that's just a sign we need redesigned operating systems, not an additional layer which has real hardware costs![3] The author of this paper laments that "when you virtualize, it is more difficult to optimize resource usage, since applications do not know how to play along in the grand ecosystem", but this is one problem which operating systems have been solving fairly well for decades—or at least a lot of effort has been putting into solving these hard problems, and there's no sense in splitting that effort into hypervisor solutions. [1] which is really just the intersection of the other two; each provides an abstraction to the user that it is the only consumer of the hardware resources—equivalently, an abstraction to the application that its virtual machine is the only consumer of the hardware resources. [2] Yes, hypervisors do some different tasks than OS, but I think that's largely for two reasons, which are accidental as opposed to fundamental: 1) In order to make existing operating systems work without (much) modification, the hypervisor has to do hardware abstraction in a less abstract way, so to speak, than the OS can offer to processes. 2) At the CPU level, designers of the virtualization interface had both hindsight and freedom to improve the interfaces for hypervisor–OS interaction as compared to OS–application interaction. [3] Examples of hardware costs are more memory usage by separate kernels and additional context switch cost between kernels. With regards to doing a better job of it (and thus removing the current need for hypervisors for this task) I think moving away from POSIX/UNIX could help; the author has many points raised against operating systems that are really only valid criticism of *NIX. [4] Any claim that hypervisors offer greater isolation between users/applications is either 1) a small result of the improvements in technology discussed in [2], or 2) a misunderstanding of the situation, where less (visible) work has been put into compromising hypervisors instead of OSes, but we have seen hypervisor exploits nonetheless.